调试锁定-Systemd丢失了我的日志

自从我在Arch Linux上“升级”到systemd以来，当意外的锁定发生时，我一直会丢失日志。我在一个月前遇到了同一本日志丢失的问题，然后再次遇到了该问题。也有独立的其他确认。

情况：

• 在用Java和与网络相关的实用程序做一些工作时，我看到KDE（时钟）被冻结了。CPU风扇变得嘈杂，并且热量不断升高。鼠标指针仍然可以移动。
• 我试图从另一台计算机上进行ssh（由于“没有路由到主机”而失败）
• 我等了几分钟，也许NMI看门狗可以杀死令人讨厌的任务。没有骰子。
• Ctrl+ Alt+ F1没有任何工作，即使经过SysRq+R
• 由于上述步骤无效，因此我决定发布SysRq序列REI。之后E，屏幕变黑，但也没有控制台。SysRq+ 之后也没有K
• 因此，该会话似乎丢失了，唯一可以做的就是收集调试信息。看Wikipedia时，我决定按SysRq+ d（显示锁）。
• 按SysRq+之后，S我等待了一秒钟，然后使用SysRq+ 重新启动B。
• 重新启动并登录到控制台后，我看不到任何崩溃的痕迹。最近记录的条目来自使用Wireshark，但仍然有45分钟的间隔。

（我正在运行Linux v3.8-rc5-218-ga56e160 btw）

因此，当由于锁定而异常重启时，如何确保我的日志得以保留？

因此，我在#systemd IRC通道上询问，事实证明日志记录（systemd的日志记录守护程序）根本不会定期将日志刷新到磁盘。这意味着您的日志始终随时处于危险之中。

发送SIGUSR2到journald原因日志将被写入磁盘，但是如果您多次执行此操作，将会创建许多文件。（该选项实际上被描述为“日志旋转”）。

最后，我决定提出另一个建议：使用专用的syslog守护程序收集内核日志。由于建议使用rsyslog（并且我已经有过使用经验），因此我进一步探讨了该选项。我已经在Arch Wiki中编写了有关使用rsyslog的更多详细信息。

这个想法是运行rsyslog，仅从内核工具中收集数据。由于rsyslog从/proc/kmsg（仅允许一个读取器）读取/dev/kmsg日志，而从rsyslog从（允许多个读取器）读取日志，因此守护程序无法丢失日志（对我来说非常重要！）。配置rsyslog以将内核消息写入文件，并确保旋转该文件以防止占用磁盘空间。

这个解决方案不是完美的：

• 其他日志（例如，来自NetworkManager的日志）将丢失。这可以通过将更多日志从syslog转发到日志来解决（这意味着重复！）。
• 日志重复。内核消息被写入两个文件。这不是问题，通常日志的数量很少，并且您宁愿拥有更多的日志副本而不是没有副本。您还可以grep在单个日志文件上使用速度更快的工具，或者使用速度较慢但更奇特的工具journalctl。

有一个TODO项可以更频繁地刷新日志，但这仍然不够可靠：

日志：不时发送标记消息，然后立即与fdatasync（）同步，以保证每小时进行一次同步。

现在，希望systemd / journald可以选择将日志写入磁盘，但是与此同时，我们可以组合工具以实现目标。

有两个更新：

1. 现在，希望systemd / journald可以选择将日志写入磁盘，但是与此同时，我们可以组合工具以实现目标。

有一个选项--sync：

要求日志守护程序将所有尚未写入的日志数据写入后备文件系统，并同步所有日志。在同步操作完成之前，该调用不会返回。此命令保证在调用之前写入的所有日志消息在返回时都安全地存储在磁盘上。

--sync有效期v228：

journalctl获得了一个新的“ --sync”开关，该开关要求日志后台驻留程序将到目前为止所有未写入的日志消息写入磁盘，并在返回之前同步文件。

2. 事实证明，日志记录（systemd的日志记录守护程序）根本不会定期将日志刷新到磁盘。这意味着您的日志始终随时处于危险之中。

man journald.conf(5) 说：

SyncIntervalSec =

将日志文件同步到磁盘之前超时。同步后，日记文件将处于OFFLINE状态。请注意，在记录了优先级CRIT，ALERT或EMERG的日志消息后，将立即无条件进行同步。因此，此设置仅适用于ERR，WARNING，NOTICE，INFO，DEBUG级别的消息。默认超时为5分钟。

SyncIntervalSec=有效期v199：

journald现在将在每次写入后最近5分钟内将日志文件显式刷新到磁盘。然后，该文件还将被标记为脱机，直到下一次写入为止。如果发生崩溃，这将提高可靠性。可以通过journald.conf中的SyncIntervalSec =来配置同步延迟。

也可以看看：

记录日志：以低优先级调度SIGTERM / SIGINT

让我们确保在退出前处理所有排队的日志数据，以免在关闭时不必要地丢失消息。