我的 Ubuntu 18.04 Intel NUC 的系统日志被这些错误消息淹没:
udisksd[1369]: udisks_mount_get_mount_path: assertion 'mount->type == UDISKS_MOUNT_TYPE_FILESYSTEM' failed
我发现垃圾邮件是由于安装了 Docker 并运行了一些容器而导致的。但是当 Docker 和所有容器停止时,系统日志中也会出现错误,但并不常见。谷歌搜索此错误消息并没有给我带来任何帮助。这与硬件无关,因为我更换了 NUC,并且我有一个配置类似的 NUC 在运行,它没有出现此错误。
有人知道如何调查这个问题吗?
答案1
我终于解决了:就我而言,这实际上与 Docker 有关。我在问题中说我停止了 Docker,但问题仍然存在。这仍然是事实。问题是由于在启用 Docker 自动启动的情况下启动时,它试图启动一个容器,该容器在启动时不存在的 LUKS 设备上有一个卷。停止 Docker 后,udisksd 日志垃圾邮件仍然存在。我通过禁用容器的自动启动解决了这个问题,该容器的卷在启动时不存在的磁盘上。之后没有出现任何错误,我可以手动启动容器。感谢您的输入。
答案2
当某些应用程序没有将有效/正确的文件系统类型输入到 statvfs 之类的程序中时,就会发生这种情况。
如果所讨论的存储由 udisk 子系统处理,则最终这将冒泡到 udisksd。
我在 Ubuntu 18.04 上安装“swapspace”时遇到了这种情况(来自 repo,通过源 zip 的当前版本确认)。
如何找出凶手:这是我所做的。
- 哪些电脑会出现这种情况?只有那些我最近移至交换空间的电脑才会出现这种情况。
- 它出现在哪些日志文件中?通常的日志文件,但也出现在消息 谁在 Ubuntu 系统上写消息...会出现一个标志:某处编码错误,有人发布了一些未正确编码的内容,无法在 Ubuntu/Debian 上运行
- 消息何时出现?就我而言,每 5 分钟会出现一次,仅在最近收到交换空间的主机上出现(为了防止浏览器锁定和浏览器图像的虚拟图像大小过度增长,请更好地管理交换空间)
一旦确定哪个应用程序导致在存储相关调用中出现无效的文件系统描述符:
stop the application (I mounted a swap partition and emptied all swapfile files into it) remove files the app is creating if possible, or move everything over, get to a clean environment where the app starts up 'new' (I deleted all swap files after everything was offloaded again to the traditional swap partition)
启动有问题的应用程序。在我的情况下,一开始什么也没发生,它必须先执行一些交换文件,然后才能丢失弹珠。在交换文件的情况下,它是使用 glibc 内部变量来分配交换文件类型,那么,glibc 可能会使用它的变量并更改内容,甚至使用它....使用交换空间放在那里的东西?此外,交换空间中的其他错误也导致发出的类型实际上永远不可能正确....
让应用程序生成错误。我确实创建了一种情况,一旦交换文件存在,交换空间实际上必须按照它所说的去做,消息确实会出现(在这种情况下,消息是否与交换空间拥有的文件有关并不重要,这可能是交换空间实际更改该变量的结果,幸运的是这里很简单,它们都与交换文件有关)
找出错误出现的条件。就我而言:交换空间 cron 运行时每 5 分钟一次,以及每次我操作交换文件时(通过适当的交换空间命令)。
在调用冒泡到 udisks 子系统之前,会发生很多事情。消息说 udisk 在调用中收到了无效代码。在此之前,有一整棵调用树最终进入 udisks。
它确实需要大量的日志文件挖掘、干净的启动(一旦我识别了交换空间,有和没有,将最近更改的系统与“永远运行”的系统进行比较),然后我进入交换空间源并查看哪里有可能导致这种情况的文件系统交互,并发现一些自负的程序员留下的一大堆粪便,从未检查或测试过适当的......
那么更重要的问题是:现在怎么办,狗追上了公交车,接下来怎么办。
我不与他们争开源自我,脸皮薄,野心勃勃,没有后盾的开源 ID-10ts。
我使用开源的真正原因:不是质量,哦不,大多数是业余打字员试图使用开源来打动女孩,看起来是这样。
在封闭系统中,我现在又回到了原点(需要修复我的交换)
在开源中:我只需要不到一个小时的时间来检查当前源代码,替换所有弃用的系统调用,并且(大约 10 分钟)找到其中特定 glibc 变量的所有非法使用并解决它。
所以是的,虽然开源质量很低,但是由那些对设计、测试、验证、试点一无所知的自负狂人完成的,对于他们来说,背景和范围是无话可说的:我不需要等待别人为我解决任何问题。
然而,坚持对这样的大失误进行“正确提交”将会导致通常的情况发生:人们会因“开源不起作用”而感到沮丧,我们都会失败。因为我遇到的这个特定问题实际上会导致严重的“无关”数据丢失、系统挂起、混乱和破坏,世界末日来临。(记住,改变了 glibc 内部变量。)
我的希望:
更改开源:
除非同行评审并签字,否则不接受任何代码,同行之间至少有一个合格的同行(计算机科学学位、数学、物理学也行)。系统关键项目上不允许业余程序员。长时间做错事而不被发现并不能使任何人成为专家。
..并定义同行评审..确保工作完成,这意味着:症状,错误影响分析,修复,正确性,影响分析,验证,单元测试,系统测试,发布测试,所有这些都需要完全协议化,并且测试协议需要正确记录,程序员可能永远不会认证他们自己的工作!