ロックアップのデバッグ-systemdがログを失う

Arch Linuxでsystemdに「アップグレード」して以来、予期しないロックアップが発生するとログが失われ続けます。私はヒットと同じログ失う問題を 1ヶ月前ともう一度問題を打ちます。他にも独立した確認があります。

状況：

• Javaやネットワーク関連のユーティリティでいくつかのことをしているときに、KDE（クロック）がフリーズしているのを見ました。CPUファンが騒々しくなり、熱が高まっていました。ただし、マウスポインタは移動できます。
• 別のマシンからsshしようとした（「ホストへのルートがない」ために失敗した）
• 私は数分待った、おそらくNMIウォッチドッグは問題のあるタスクを殺すことができた。サイコロはありません。
• Ctrl+ Alt+はF1した後でも、どちらか動作しませんでしたSysRq+R
• 上記の手順がうまくいかなかったので、SysRqシーケンスREIを発行することにしました。の後E、画面は黒くなりましたが、コンソールもなくなりました。SysRq+の後もK
• したがって、このセッションは失われたように見えます。実行できる唯一のことは、デバッグ情報を収集することです。ウィキペディアを見て、いくつかの中でSysRq+ d（保留中のロックを表示）を押すことにしました。
• SysRq+ Sを押した後、少し待ってからSysRq+で再起動しましたB。
• 再起動してコンソールにログインした後、クラッシュの痕跡は見られませんでした。最近記録されたエントリはWiresharkの使用によるものでしたが、それでも45分のギャップがありました。

（私はLinux v3.8-rc5-218-ga56e160 btwを実行していました）

では、ロックアップが原因で異常に再起動したときに、ログを確実に保持するにはどうすればよいですか？

それで、私は#systemd IRCチャネルで尋ねました、そして、journald（systemdのロギングデーモン）が定期的にログをディスクにフラッシュしないことがわかりました。これは、ログがいつでも危険にさらされていることを意味します。

原因に送信SIGUSR2すると、journaldログがディスクに書き込まれますが、これを複数回行うと、多くのファイルが作成されます。（このオプションは実際には「ログローテーション」と呼ばれます）。

結局、私は別の提案を行うことにしました。カーネルログを収集するために専用のsyslogデーモンを使用することです。rsyslogが提案された（そして私はすでにそれを経験していた）ので、私はそのオプションをさらに探索しました。Arch Wikiで、rsyslogの使用に関する詳細を書きました。

アイデアは、rsyslogを実行して、カーネル機能からデータのみを収集することです。rsyslogは/proc/kmsg（単一のリーダーのみを/dev/kmsg許可）から読み取り、journaldは（複数のリーダーを許可）から読み取るため、デーモンがログを失う方法はありません（私にとって非常に重要です）。カーネルメッセージをファイルに書き込むようにrsyslogを構成し、このファイルがローテーションされてディスクスペースを消費しないようにします。

このソリューションは完璧ではありません：

• 他のログ（NetworkManagerなどから）は失われます。これは、syslogからjournaldにさらにログを転送することで解決できます（これは複製を意味します！）
• ログの複製。カーネルメッセージは2つのファイルに書き込まれます。これは問題ではありません。一般に、ログの数は少なく、ログのコピーはなしよりも多くしたいでしょう。grep単一のログファイルなどの高速ツールを使用することもできますが、より低速ですがより洗練されていjournalctlます。

ログをより頻繁にフラッシュするためのTODO項目がありますが、それでも十分な信頼性はありません。

ジャーナル：時々保証された同期を行うために、マーカーメッセージを時々送信し、その後すぐにfdatasync（）と同期します。

うまくいけば、systemd / journaldがログをディスクに書き込むオプションを取得できるようになりますが、その間、ツールを組み合わせて目標を達成できます。

2つの更新があります。

1. うまくいけば、systemd / journaldがログをディスクに書き込むオプションを取得できるようになりますが、その間、ツールを組み合わせて目標を達成できます。

オプションがあります--sync：

まだ書き込まれていないすべてのジャーナルデータをバッキングファイルシステムに書き込み、すべてのジャーナルを同期するようジャーナルデーモンに要求します。この呼び出しは、同期操作が完了するまで戻りません。このコマンドは、呼び出しの前に書き込まれたログメッセージが返されたときにディスクに安全に保存されることを保証します。

--sync以降利用可能v228：

journalctlは新しい "--sync"スイッチを取得しました。これは、これまでに書き込まれていないすべてのログメッセージをディスクに書き込み、戻る前にファイルを同期するようジャーナルデーモンに要求します。

2. journald（systemdのロギングデーモン）が定期的にログをディスクにフラッシュしないことがわかります。これは、ログがいつでも危険にさらされていることを意味します。

man journald.conf(5) 言う：

SyncIntervalSec =

ジャーナルファイルをディスクに同期する前のタイムアウト。同期後、ジャーナルファイルはOFFLINE状態になります。同期は、優先度がCRIT、ALERT、またはEMERGのログメッセージがログに記録された直後に無条件に行われることに注意してください。したがって、この設定はERR、WARNING、NOTICE、INFO、DEBUGレベルのメッセージにのみ適用されます。デフォルトのタイムアウトは5分です。

SyncIntervalSec=以降利用可能v199：

journaldは、各書き込み後の遅くとも5分後に、明示的にジャーナルファイルをディスクにフラッシュします。その後、ファイルは次の書き込みまでオフラインとしてマークされます。これにより、クラッシュした場合の信頼性が向上します。同期遅延は、journald.confのSyncIntervalSec =で設定できます。

以下も参照してください。

journald：SIGTERM / SIGINTを低い優先度でディスパッチします

終了する前にすべてのキューに入れられたログデータを処理して、シャットダウン時にメッセージが失われないようにしましょう。