崩溃：systemd-journal 无法写入条目。忽略：仅限只读文件系统

Question 1

简短回答：按照建议Arch wiki 上，尝试更新你的 SSD 的固件。

现在为什么，（仅针对那些想了解我是如何得出这个结论的人，也许可以在这种类型的故障排除中学习到一些有用的技巧 - 或者更好的是，根据需要礼貌地纠正我）：

我也遇到了同样的问题，我也有 Ubuntu 18.04。我的根分区安装在三星 SSD 860 EVO 500GB 上。你似乎有一个 ADATA SSD。

我看到很多帖子都提到了这个问题，没有解决方案，通常的答案警告 SSD 文件系统可能存在问题、设备损坏等。我不这么认为。

对于 SSD，Ubuntu 默认启用定期 TRIM。fstrim.service每周通过进行一次。

根据man fstrim：

Running fstrim frequently, or even using mount -o discard, 
might negatively affect the lifetime of poor-quality SSD devices. 
For most desktop and server systems a sufficient trimming frequency is once a week. 
Note that not all devices support a queued trim, so each trim command 
incurs a performance penalty on whatever else might be trying to use the disk at the time.

...这让我想到了以下场景以及我自己的场景假设（下面我将通过我自己的研究来支持这一点）：

当fstrim运行时（在本例中为每周），它肯定需要锁定正在整理的文件系统。与此同时，journald 试图将一些日志写入/var/log/journal/，但它发现无法写入（在我看来，因为无论如何fstrim它都忙于或忙于 SSD）。因此，它的投诉是：。/journaldFailed to write entry (...) Read-only file system

这时你可能会插话说：“但是：等等！这没有意义。”好吧，确实，这些服务不应该同时争夺写入文件系统或锁定文件系统。但最引人注目的线索来自上述man页面的引用：请注意，并非所有设备都支持排队修剪，因此每个修剪命令都会对当时试图使用磁盘的其他任何设备造成性能损失。

...这与我们在启动当天看到的情况一致，我们fstrim.service决定以非常粗鲁的方式执行其操作，完全无视异步服务应该遵循的预期“礼仪”。

事实上，如果你journalctl -u fstrim.service像我一样看一下，你可能会看到与此类似的许多块的序列：

-- Reboot --
Jul 13 00:00:13 foo systemd[1]: Starting Discard unused blocks...
Jul 13 00:02:43 foo fstrim[19452]: /Some/MountPoint: 79,4 GiB (85273759744 bytes) trimmed
Jul 13 00:02:43 foo fstrim[19452]: /: 22,4 GiB (24017248256 bytes) trimmed
Jul 13 00:02:43 foo systemd[1]: Started Discard unused blocks.

这是我一周前遇到的，当时我又遇到了上述问题。今天又出现了同样的问题。我不得不重启电脑。

请注意，“正在启动”和“已启动”之间的时间大约为 150 秒（2 分 30 秒）。在我的日志中，这个时间总是非常相似；有时可能大约为 3 到 3.5 分钟，不会更多。并且没有任何信息表明（就我而言）修剪失败。要么服务没有记录成功或失败（我不知道），要么这些消息显示“完成”。

在我的假设中，这听起来可能仍然很奇怪，如果消息显示的间隔是几百秒，为什么这会在很长一段时间内干扰日志写入？（哦，确实如此：在这种情况下我已经等了很长时间，但错误还是不断出现！）。好吧，我只能猜测错误只会在重试几次后出现，或者系统有太多错误排队等待打印到终端，不知何故，这变得非常慢。这只是我的猜测：如果有人能以技术上准确的方式解释这一点，请务必帮助或纠正我。

但事实是，在启动时“几乎挂起”之后，日志就会损坏。就我而言，我在 dmesg 的输出中看到了这一点，就在“半挂起”之后的下一次成功启动时：

[   10.986870] systemd-journald[434]: File /var/log/journal/414716237ed94301a0e84b4204143c5b/system.journal corrupted or uncleanly shut down, renaming and replacing.

这是有道理的，因为我进行了强制重启。

最后一点也是我假设的重点是，我的（可能还有你的）SSD 设备缺乏对排队修剪的支持。在我的假设中，好消息是，这意味着我们的 SSD 文件系统或硬件没有损坏。这意味着我们在处理服务尝试创建system.journal的文件时遇到了麻烦。system-journald

和，简短回答：最重要的是，我们应该尝试更新 SSD 的固件。

Answer

简短回答：按照建议Arch wiki 上，尝试更新你的 SSD 的固件。

现在为什么，（仅针对那些想了解我是如何得出这个结论的人，也许可以在这种类型的故障排除中学习到一些有用的技巧 - 或者更好的是，根据需要礼貌地纠正我）：

我也遇到了同样的问题，我也有 Ubuntu 18.04。我的根分区安装在三星 SSD 860 EVO 500GB 上。你似乎有一个 ADATA SSD。

我看到很多帖子都提到了这个问题，没有解决方案，通常的答案警告 SSD 文件系统可能存在问题、设备损坏等。我不这么认为。

对于 SSD，Ubuntu 默认启用定期 TRIM。fstrim.service每周通过进行一次。

根据man fstrim：

Running fstrim frequently, or even using mount -o discard, 
might negatively affect the lifetime of poor-quality SSD devices. 
For most desktop and server systems a sufficient trimming frequency is once a week. 
Note that not all devices support a queued trim, so each trim command 
incurs a performance penalty on whatever else might be trying to use the disk at the time.

...这让我想到了以下场景以及我自己的场景假设（下面我将通过我自己的研究来支持这一点）：

当fstrim运行时（在本例中为每周），它肯定需要锁定正在整理的文件系统。与此同时，journald 试图将一些日志写入/var/log/journal/，但它发现无法写入（在我看来，因为无论如何fstrim它都忙于或忙于 SSD）。因此，它的投诉是：。/journaldFailed to write entry (...) Read-only file system

这时你可能会插话说：“但是：等等！这没有意义。”好吧，确实，这些服务不应该同时争夺写入文件系统或锁定文件系统。但最引人注目的线索来自上述man页面的引用：请注意，并非所有设备都支持排队修剪，因此每个修剪命令都会对当时试图使用磁盘的其他任何设备造成性能损失。

...这与我们在启动当天看到的情况一致，我们fstrim.service决定以非常粗鲁的方式执行其操作，完全无视异步服务应该遵循的预期“礼仪”。

事实上，如果你journalctl -u fstrim.service像我一样看一下，你可能会看到与此类似的许多块的序列：

-- Reboot --
Jul 13 00:00:13 foo systemd[1]: Starting Discard unused blocks...
Jul 13 00:02:43 foo fstrim[19452]: /Some/MountPoint: 79,4 GiB (85273759744 bytes) trimmed
Jul 13 00:02:43 foo fstrim[19452]: /: 22,4 GiB (24017248256 bytes) trimmed
Jul 13 00:02:43 foo systemd[1]: Started Discard unused blocks.

这是我一周前遇到的，当时我又遇到了上述问题。今天又出现了同样的问题。我不得不重启电脑。

请注意，“正在启动”和“已启动”之间的时间大约为 150 秒（2 分 30 秒）。在我的日志中，这个时间总是非常相似；有时可能大约为 3 到 3.5 分钟，不会更多。并且没有任何信息表明（就我而言）修剪失败。要么服务没有记录成功或失败（我不知道），要么这些消息显示“完成”。

在我的假设中，这听起来可能仍然很奇怪，如果消息显示的间隔是几百秒，为什么这会在很长一段时间内干扰日志写入？（哦，确实如此：在这种情况下我已经等了很长时间，但错误还是不断出现！）。好吧，我只能猜测错误只会在重试几次后出现，或者系统有太多错误排队等待打印到终端，不知何故，这变得非常慢。这只是我的猜测：如果有人能以技术上准确的方式解释这一点，请务必帮助或纠正我。

但事实是，在启动时“几乎挂起”之后，日志就会损坏。就我而言，我在 dmesg 的输出中看到了这一点，就在“半挂起”之后的下一次成功启动时：

[   10.986870] systemd-journald[434]: File /var/log/journal/414716237ed94301a0e84b4204143c5b/system.journal corrupted or uncleanly shut down, renaming and replacing.

这是有道理的，因为我进行了强制重启。

最后一点也是我假设的重点是，我的（可能还有你的）SSD 设备缺乏对排队修剪的支持。在我的假设中，好消息是，这意味着我们的 SSD 文件系统或硬件没有损坏。这意味着我们在处理服务尝试创建system.journal的文件时遇到了麻烦。system-journald

和，简短回答：最重要的是，我们应该尝试更新 SSD 的固件。

Question 2

尝试升级你的内核。

在最近更新 Ubuntu 20.04 后，我每天晚上都会遇到同样的“写入条目”崩溃。

我使用的是廉价的 SSD，没有 DRAM，也没有其他答案建议的更新固件的选项。最后，我在某处读到，如果内核无法正常工作，系统可能会锁定并错误地将区域标记为“只读”，因此我更新到了较新的内核 (5.7.1)，从那以后就再也没有遇到过这个问题。

这是一篇关于如何升级内核的文章

如果您怀疑问题出在内核上，并想先测试一下这个理论，您可以在重启后进入启动屏幕上的“高级选项”，然后选择一个较旧版本的内核来运行。如果该内核适合您，那么您可能希望将其设置为暂时使用的内核，因为最新的内核是未签名的，需要您自己签名或关闭安全启动。

Answer

尝试升级你的内核。

在最近更新 Ubuntu 20.04 后，我每天晚上都会遇到同样的“写入条目”崩溃。

我使用的是廉价的 SSD，没有 DRAM，也没有其他答案建议的更新固件的选项。最后，我在某处读到，如果内核无法正常工作，系统可能会锁定并错误地将区域标记为“只读”，因此我更新到了较新的内核 (5.7.1)，从那以后就再也没有遇到过这个问题。

这是一篇关于如何升级内核的文章

如果您怀疑问题出在内核上，并想先测试一下这个理论，您可以在重启后进入启动屏幕上的“高级选项”，然后选择一个较旧版本的内核来运行。如果该内核适合您，那么您可能希望将其设置为暂时使用的内核，因为最新的内核是未签名的，需要您自己签名或关闭安全启动。

Question 3

我们网络上的某个人意外地将以太网电缆插入一个端口，然后又环回到同一 VLAN 上的另一个端口。显然，这造成了混乱，导致网络瘫痪……

这导致我们网络上的许多 Linux VM 进入此 systemd-journald 写入错误循环。对于大多数主机来说，只需重新启动即可解决问题，其他主机则有损坏的分区，我需要运行fsck（请参阅这里）解决。

Answer

我们网络上的某个人意外地将以太网电缆插入一个端口，然后又环回到同一 VLAN 上的另一个端口。显然，这造成了混乱，导致网络瘫痪……

这导致我们网络上的许多 Linux VM 进入此 systemd-journald 写入错误循环。对于大多数主机来说，只需重新启动即可解决问题，其他主机则有损坏的分区，我需要运行fsck（请参阅这里）解决。

崩溃：systemd-journal 无法写入条目。忽略：仅限只读文件系统

答案1

简短回答：按照建议Arch wiki 上，尝试更新你的 SSD 的固件。

答案2

答案3

相关内容