Linux内核开发人员默认决定将消息速率限制为/ dev / kmsg。这是因为它们不喜欢systemd编写的消息量，尤其debug是在内核命令行上传递消息时。
即使未启用调试消息，systemd也会超过此限制。
[ 5.879211] systemd: 18 output lines suppressed due to ratelimiting
这是目前我的内核日志（dmesg）中唯一的此类消息。因此，我可能认为这意味着仅丢失了18条连续的行，在t = 5.879211附近结束。从某种意义上讲，这将是一个相当有限的损失。除非我注意到某些早期启动单元（journald）开始出现故障，否则我可能不必担心。
所以，对吗？在这种情况下，这种分析可能会误导我吗？
实际上，这个想法是错误的。首先，该消息不一定代表丢失的18个连续系统消息的单个块。其次，您无法确定/ dev / kmsg何时受速率限制，如果该进程仍可打开以进行写入。一旦进程关闭/ dev / kmsg，您只会收到有关此消息。该消息显示来自该编写器的所有禁止的行数。
每个单独的编写器（文件描述符）都将/dev/kmsg获得其自己的ratelimit结构。作为初始化的一部分...
ratelimit_set_flags(&user->rs, RATELIMIT_MSG_ON_RELEASE);
ratelimit设置为仅登录发布。也就是说，当文件描述符关闭时。对于一个长时间运行的过程，这可能没有什么用处……而init系统（即systemd）绝对算是一个长时间运行的过程。
您看到此日志消息的原因是，从initrd发出的systemd在exec()从系统根文件系统进行systemd之前已关闭/ dev / kmsg 。
因此，在initrd期间丢失的消息不一定会作为一个块丢失。丢失的消息可能有几个不同的块，因此日志不会像我想的那样简单直接地进行分析。
exec()从根文件系统到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。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句