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

Linux 核心開發人員預設決定將消息速率限製到 /dev/kmsg。這是因為他們不喜歡 systemd 寫入的消息量，尤其debug是在核心命令行上傳遞時。

即使沒有啟用調試消息，systemd 也會超過此限制。

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

這是目前我的核心日誌 ( dmesg) 中唯一的此類消息。所以我可能認為這意味著只有 18 行連續失去，在 t=5.879211 左右結束。從某種意義上說，這將是相當有限的損失。除非我注意到一些非常早期的引導單元（期刊前）出現故障，否則我可能不需要擔心它。

那麼，對嗎？是否存在這種分析可能誤導我的情況？

其實這個想法是非常錯誤的。首先，該消息不一定代表已失去的 18 條連續 systemd 消息的單個塊。其次，您無法判斷 /dev/kmsg 何時已被速率限制，如果該程序仍然打開以供寫入。只有在程序關閉 /dev/kmsg 後，您才會收到有關它的消息。該消息顯示來自該作者的所有抑制行的計數。

---

每個單獨的編寫器（文件描述符）/dev/kmsg獲取它自己的 ratelimit 結構。 作為初始化的一部分……

ratelimit_set_flags(&user->rs, RATELIMIT_MSG_ON_RELEASE);

ratelimit 設置為僅登錄發布。也就是說，當文件描述符關閉時。對於一個長時間執行的程序，這可能沒有多大幫助……並且init系統，即systemd絕對算作一個長時間執行的程序。

exec()您看到此日誌消息的原因是 initrd 中的 systemd 在系統根文件系統中的 systemd之前關閉了 /dev/kmsg 。

因此，在 initrd 期間失去的消息不一定會作為一個塊失去。可能有幾個不同的失去消息塊，因此日誌不會像我想像的那樣簡單易懂。

此外，從exec()根文件系統 ing systemd 到 systemd 完全停止記錄到 /dev/kmsg 並切換到journald. 確實是這樣，我們可以在關機期間看到（使用保持開啟的控制台，如串列控制台）。systemd exec()s 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。

引用自：https://unix.stackexchange.com/questions/420133