ロギング · レッスン 4

カーネルロギング

dmesg と journalctl を使い、現在および保存済みの Linux カーネルメッセージを問い合わせる方法を学びます。

カーネルは boot、driver、device、filesystem、networking、memory、failure に関するメッセージを発します。これらのレコードは低レベルの症状を説明できますが、一つの warning 文字列だけでハードウェア故障を証明することはできません。

カーネル Ring Buffer を読む

dmesg はカーネル ring buffer のメッセージを読みます。

$ dmesg --human

buffer の容量は有限なので、新しいメッセージが古いものを上書きする場合があります。アクセスが特権ユーザーに制限されることもあります。対応実装では dmesg --follow で新しいカーネルメッセージを追跡できます。範囲を限定した再現後に停止してください。

古いカーネルイベントが現在の dmesg 出力にない場合があるのはなぜですか？

読みやすい Timestamp を使う

生のカーネル timestamp は通常 boot からの相対時間です。dmesg --ctime または --human は wall-clock time へ変換できますが、変換値は時計の履歴に依存し、boot 後に時計が変わると不正確になる場合があります。正確な順序が重要なら boot-relative timing を保持してください。

変換済み dmesg の wall-clock timestamp を慎重に扱うべきなのはなぜですか？

永続的なカーネルレコードを問い合わせる

systemd ホストでは、現在の boot のカーネルレコードを問い合わせます。

$ journalctl -k -b

persistent journal storage が以前の boot を保持している場合、boot list を調べて一つ選びます。

$ journalctl --list-boots
$ journalctl -k -b -1

従来の syslog routing が /var/log/kern.log などを作る場合がありますが、設定によって異なります。保存済み /var/log/dmesg も普遍的ではなく、boot 時の snapshot にすぎない場合があります。

保存されている一つ前の boot のカーネルメッセージを要求するコマンドはどれですか？

カーネルイベントを調査する

boot、timestamp、device、subsystem、その時点の操作を特定します。周辺の kernel record と service record を問い合わせ、hardware inventory と現在状態を比較します。

$ journalctl -k -b --since '10 minutes ago'
$ lspci -k
$ lsblk

subsystem に関係するツールだけを使ってください。driver の reload、device の unbind、reboot の前に、storage、network、console、service への影響を評価し、復旧アクセスを確保します。

一つのカーネル warning 行に対する最善の対応はどれですか？

レッスン完了