まずホスト全体のロックアップとネットワーク障害を区別する
報告されたマシンでは、ネットワークアクセス、ping、コンテナ、ローカルコンソールの応答、映像出力がすべて失われました。これは SMB、Docker、または NIC の障害よりも広範囲であり、電源の入れ直しが必要なホスト全体のロックアップと一致します。
サーバーがリモートから見えなくなった場合は、交換用 NIC を購入する前に、ローカルコンソールとディスプレイを確認してください。コンソールが応答するなら調査の方向はネットワーク障害となり、コンソールがフリーズしてディスプレイ表示も失われているなら、カーネル、ファームウェア、電源、ストレージ、またはハードウェアの問題へと絞り込まれます。
正確な発生時刻と、マシンが自動的に再起動したのか、それとも電源は入ったまま応答しなくなったのかを記録してください。これらの観察結果によって、比較すべき直前の起動期間と外部監視データが決まります。
変数を変更する前に、直前の起動の証拠を収集する
このトピックで最初に収集された有用な情報は次のとおりです。 journalctl -b -1フリーズに至った起動時のカーネルメッセージと高優先度メッセージを含めて、ZimaOS チームは後に、直前の起動から最後の 500 件のエントリと永続ジャーナルを非公開で確認するよう求めました。
ログを公開する前に、個人情報が含まれていないか確認してください。このケースでは永続ジャーナリングが有効でしたが、パニック、OOM キル、GPU リセット、ストレージエラー、温度異常、ウォッチドッグによるロックアップ、正常なシャットダウンのいずれも記録されないまま、観測された障害時刻でログが突然途切れていました。
最後の記録が空であっても、何も失敗しなかったことを意味するわけではありません。利用可能なローカルログ収集経路が原因を記録する前に、ホストが停止したことを示しています。同じような無言のロックアップが起きるたびに同じログコマンドを繰り返しても、取得方法を変えない限り得られるものはほとんどありません。
GPU と Frigate のテストでは解決策を特定できなかった
システムでは Intel i915 グラフィックスと Frigate VAAPI を使用していたため、筆者はまず GPU アクセラレーションを無効にしました。それでもホストはフリーズしました。一時的に Frigate を完全に停止すると、ある時点ではより長い間隔が得られましたが、その後のテストでは Frigate が原因だとは特定できませんでした。
筆者は i915 の無効化も試しましたが、他のワークロードが使用不能になり、最終的にシステムは再びクラッシュしました。この結果から、このケースでは「i915 を無効にする」ことが有効な修復策ではないと判断できます。
OpenMediaVaultとの比較には意味がありました。同じハードウェアとFrigateの構成は、そこで安定して動作していました。これはZimaOS固有のカーネルまたはドライバーの相互作用への疑いを強めますが、どのコンポーネントが失敗したかをそれだけで特定するものではありません。
IOMMU、VFIO、SATA LPMの提案は解決策として却下された
ZimaOSには当初、次が含まれていました intel_iommu=on および vfio_iommu_type1.allow_unsafe_interrupts=1。チームメンバーは著者に両方を削除するよう求めました。アクティブなコマンドラインで両方が存在しないことが確認されましたが、それでもマシンは再びロックしました。
その後、著者はテストしました libata.force=nolpm データディスクがM.2-SATAアダプターを使用していたためです。翌朝、別のフリーズが発生しました。したがって、このスレッドはどちらの起動パラメーター変更も解決策として支持していません。
これらのテストは、更新によって実験条件が無効になる可能性がある理由も示しています。ある更新でカスタマイズしたコマンドラインファイルが上書きされていました。稼働時間を解釈する前に、アクティブな起動コマンドラインを必ず確認し、確立されたクラッシュ発生時間帯では変数を1つだけ変更してください。
永続ジャーナル、pstore、リモートフォワーディングは限界に達した
カーネルにはpstoreとハード／ソフトロックアップ検出機能が含まれており、NMIウォッチドッグも有効でした。しかし、 /sys/fs/pstore クラッシュ後も空のままで、kdump用のクラッシュカーネルは予約されていませんでした。
起動時のnetconsoleは設定を解析しましたが、開始前に eth0 は存在していましたが、自動的に無効化されました。ユーザー空間の journalctl-to-UDPフォワーダーは2台目のLinuxマシンに到達しましたが、ホストがフリーズすると最終的な原因を示さないまま停止しました。
この結果は有用です。スケジューラーやネットワークスタックが停止した後は、ユーザー空間のフォワーディングでメッセージを送信できず、発生していないカーネル警告を生成することもできません。この時点では、同一内容のユーザー空間キャプチャーをもう一度行うより、ベンダー提供のデバッグカーネルや対象を絞った計装のほうが有益です。
ZimaOS 1.7.1で疑わしいコンポーネントを変更したが、まだ検証されていなかった
ZimaBoard 2の別のユーザーは、ロックアップの直前にPythonなどのプロセスが繰り返しクラッシュしたと報告しました。ZimaOSチームは、ZimaOS 1.7.1からCrudini依存関係を削除したと説明しました zimaos-welcomeそのサービスのリソース要求頻度を下げ、テストリリースに向けて変更を計画しました。
チームは後に、Crudiniの問題は単なるトリガーであり、実際のシステムクラッシュの原因はまだ調査中であると説明しました。ZimaOS 1.7.1では、コンテナーの起動を改善し、DBusブローカーのメッセージブロッキングが発生する可能性を低減するため、Docker Engineのバージョンもロールバックしました。
最後の投稿では、別のユーザーが1.7.1で安定しているかどうかを尋ねていますが、必要な稼働時間の結果は示されていません。元の障害条件が以前の発生間隔を超えて安定した状態を維持するまで、1.7.1をロックアップの確実な修正版と説明しないでください。
すでに除外されたテストとともにエスカレーションする
十分なサポート資料には、ハードウェアモデル、ZimaOSとカーネルのバージョン、ストレージコントローラー、ワークロード、クラッシュ時刻、アクティブなブートパラメーター、前回の起動時のログ、実施したテストと結果の一覧が含まれます。
このソース事例では、GPUアクセラレーション、Frigateの切り離し、IOMMU/VFIOパラメーターの削除、i915の無効化、SATA LPMの変更、永続ログ、pstore、リモートユーザー空間ロギングのいずれによっても、修復が確認されなかったことを明確に記載してください。
同じワークロードで別のオペレーティングシステムが安定している一方、ZimaOSではロックアップが続く場合は、その比較結果を保持し、対象を絞ったビルドまたはベンダーによる調査を依頼してください。信頼性が運用上重要な場合は、未検証のパラメーターを際限なく追加するのではなく、安定した環境に戻すことを中止の妥当な判断基準とできます。
FAQ
FrigateまたはIntel VAAPIがZimaOSのクラッシュを引き起こしましたか？
このスレッドでは証明されていません。GPUアクセラレーションを無効にした後も、さらにi915の切り離しテストを行った後もクラッシュは続きました。
IOMMUとVFIOのパラメーターを削除するとロックアップは解消されましたか？
いいえ。アクティブなコマンドラインで両方が削除されたことを確認しましたが、ホストは再びロックアップしました。
ZimaOS 1.7.1ではシステム全体のフリーズが解消されますか？
リリースではCrudiniが変更されました。 zimaos-welcome、Docker Engine、DBus関連の動作について触れていますが、安定性が回復したことを確認する結果が出る前に話題が終わっています。
