☰

/dev/kmsg が速度制限を受ける時期がわかりますか？

tag-icon • tag-icon linux linux-kernel systemd dmesg
/dev/kmsg が速度制限を受ける時期がわかりますか？

Linuxカーネル開発者はデフォルトで/dev/kmsgメッセージレート制限を決定しました。これは、システムが書き込むメッセージの量、特にdebugカーネルコマンドラインに渡されるメッセージの量が好きではないためです。

デバッグメッセージが有効になっていない場合でも、systemdはこの制限を超えています。

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

dmesgこれは現在私のカーネルログ（）にある唯一のメッセージです。したがって、これはt = 5.879211の近くで終わる18個の連続行だけが失われるという意味であると考えられます。ある意味では、これはかなり制限的な損失になります。非常に初期の開始単位（ジャーナル前）が失敗することを見つけない限り、心配する必要はありません。

だとしたらそうですか？場合によっては、この分析は私を誤解する可能性がありますか？

ベストアンサー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()ルートファイルシステムで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は使用されません。

おすすめ記事