![是否可以判断 /dev/kmsg 何时受到速率限制?](https://linux22.com/image/126506/%E6%98%AF%E5%90%A6%E5%8F%AF%E4%BB%A5%E5%88%A4%E6%96%AD%20%2Fdev%2Fkmsg%20%E4%BD%95%E6%97%B6%E5%8F%97%E5%88%B0%E9%80%9F%E7%8E%87%E9%99%90%E5%88%B6%EF%BC%9F.png)
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。