我的 Ubuntu 18.04 Intel NUC 的系统日志收到以下错误消息的垃圾邮件：
udisksd[1369]: udisks_mount_get_mount_path: assertion 'mount->type == UDISKS_MOUNT_TYPE_FILESYSTEM' failed
我发现垃圾邮件是由于安装了 Docker 并运行了一些容器。但是随着 Docker 和所有容器停止，错误也会出现在 syslog 中，但并不经常发生。谷歌搜索此错误消息没有得到我的任何帮助。它与硬件无关，因为我更改了 NUC，并且我有一个类似的配置 NUC 正在运行，它没有此错误。
有人知道如何调查这个问题吗？
我终于解决了：在我的情况下，它实际上与 Docker 相关。我在我的问题中说我停止了 Docker 并且问题仍然存在。这仍然是正确的。问题是由于启动时启用了 Docker 自动启动，而它试图启动一个容器，该容器在 LUKS 设备上具有一个在启动时不存在的卷。停止 Docker 后，udisksd 日志垃圾邮件仍然存在。我通过禁用容器的自动启动来解决它，该容器的卷在启动时不存在的磁盘上。之后不再出现错误，我能够手动启动容器。感谢您的输入。
当某些应用程序没有将有效/正确的文件系统类型放入 statvfs 之类的东西时，就会发生这种情况。
如果有问题的存储由 udisk 子系统处理，最终这将冒泡到 udiskd。
我在 Ubuntu 18.04 上安装“swapspace”时发生了这种情况（来自 repo，通过源 zip 的当前版本确认）。
如何找到whodunnit：这就是我所做的。
一旦您确定了您的哪个应用程序导致在与存储相关的调用中出现无效文件系统描述符：
启动有问题的应用程序。就我而言，一开始什么也没发生，它必须先做一些交换文件，然后才能丢失它的弹珠。在交换文件的情况下，它是为分配的交换文件类型使用 glibc 内部变量，好吧，glibc 可能会使用它的变量并更改内容，甚至使用它....使用放在那里的交换空间？交换空间中的其他错误也导致发出的类型实际上永远不会正确....
使应用程序生成错误。我确实创造了一种情况，即交换空间确实必须按照它所说的那样做交换空间实际上改变了那个变量，幸运的是这里很简单，它们都与交换文件有关）
找出错误出现的条件。就我而言：每 5 分钟交换空间 cron 运行一次，每次我操作交换文件时（通过正确的交换空间命令）。
在调用冒泡到 udisks 子系统之前，确实会发生很多事情。消息说 udisk 在通话中收到了无效代码。在它之前有一个完整的调用树，最终出现在 udisk 中。
确实需要大量的日志文件挖掘，干净的启动（一旦我确定了交换空间，有无，将最近更改的系统与“永远运行”的系统进行比较），然后我确实进入了交换空间源并查看了哪里有文件可能导致这种情况的系统交互，并发现了一些自我程序员留下的一大堆便便，并且从未正确检查或测试过......
那么更重要的问题是：现在，狗赶上了公共汽车，接下来会发生什么。
我不与他们对抗开源的自我，皮肤薄，野心勃勃，没有开源 ID-10ts 的支持。
我使用开源的真正原因：不是质量，哦不，大多数是业余打字员试图做开源来打动女孩，看起来是这样。
在一个封闭的系统中，我现在将回到原点（需要修复我的交换）
在开源中：检查当前源代码，替换所有已弃用的系统调用，并（大约 10 分钟）找到其中特定 glibc 变量的所有非法使用并解决它，我只需要不到一个小时的时间。
所以是的，虽然开源的质量非常低，但由对设计、测试、验证、试点一无所知的自负狂人完成，对于谁来说上下文和范围是无话可说的：我不需要等待有人修复任何东西为了我。
然而，对于像这样的大花样，坚持“正确提交”会导致通常的情况发生：人们会对“开源不起作用”感到沮丧，我们都会失败。因为我遇到的这个特殊的事情实际上会导致严重的“无关”数据丢失、系统挂起、混乱和破坏，世界走到了尽头。（记住，改变一个 glibc 内部变量。）。
我的希望：
更改开源：
除非同行评审并签字，否则不接受任何代码，同行之间至少有一个合格的同行（计算机科学学位、数学、物理学也可以）。没有对系统关键项目感兴趣的程序员。长时间做错事而不被抓住确实没有人成为专家。
.. 并定义同行评审 .. 确保工作完成，这意味着：症状、错误影响分析、修复、正确性、影响分析、验证、单元测试、系统测试、发布测试，所有这些都需要完全协议，并且测试协议需要正确记录，编码人员可能永远无法证明自己的工作！