☰

是否可以判断 /dev/kmsg 何时受到速率限制？

tag-icon • tag-icon linux linux-kernel systemd dmesg
是否可以判断 /dev/kmsg 何时受到速率限制？

Linux 内核开发人员默认决定对 /dev/kmsg 消息进行速率限制。这是因为他们不喜欢 systemd 写入的消息量，特别是debug在内核命令行上传递的消息量。

即使没有启用调试消息，systemd 也会超出此限制。

[    5.879211] systemd: 18 output lines suppressed due to ratelimiting

dmesg这是目前我的内核日志 () 中唯一的此类消息。所以我可能认为这意味着只丢失了 18 条连续的行，在 t=5.879211 左右结束。从某种意义上说，这将是相当有限的损失。我可能不需要担心它，除非我注意到一些非常早期的启动单元（期刊前）失败了。

那么，是这样吗？在某些情况下，这种分析可能会误导我吗？

答案1

其实这个想法是非常错误的。首先，该消息不一定代表 18 个连续 systemd 消息的单个块已丢失。其次，如果进程仍然开放写入，您无法判断 /dev/kmsg 何时受到速率限制。只有当进程关闭 /dev/kmsg 时，您才会收到有关它的消息。该消息显示来自该作者的所有抑制行的计数。

每个单独的编写器（文件描述符）都会/dev/kmsg获得自己的速率限制结构。 作为初始化的一部分......

ratelimit_set_flags(&user->rs, RATELIMIT_MSG_ON_RELEASE);

速率限制设置为仅登录发布。即，当文件描述符关闭时。对于长时间运行的进程来说，这可能没什么帮助......并且 init 系统（即 systemd）绝对算作一个长时间运行的进程。

您看到此日志消息的原因是，initrd 中的 systemd 在exec()系统根文件系统中的 systemd 之前关闭了 /dev/kmsg。

因此，在 initrd 期间丢失的消息不一定会作为块丢失。可能有几个不同的丢失消息块，因此日志分析起来并不像我想象的那么简单。

此外，从exec()根文件系统 ing systemd 到 systemd 完全停止记录到 /dev/kmsg 并切换到journald.确实如此，我们可以在关闭期间看到它们（使用保持打开状态的控制台，例如串行控制台）。当systemdexec()的systemd-shutdown时，/dev/kmsg会自动关闭，我们看到

[  OK  ] Reached target Final Step.
         Starting Reboot...
[   76.318839] systemd-shutdow: 32 output lines suppressed due to ratelimiting
...

这与来自内核的某些速率限制消息形成对比，例如kauditd_printk_skb: 32 callbacks suppressed。在这种情况下，不使用 RATELIMIT_MSG_ON_RELEASE。

相关内容