応答不能になり、SSHでもアクセスできなくなったZimaCubeでは、ネットワークやソケットの枯渇、クライアントとVPNの相互作用、熱による不安定化、カーネルの問題、ハードウェア障害など、まったく異なる種類の障害が発生している可能性があります。2024年のスレッドでは、どれが原因だったのかは特定できませんでした。
CMOSのリセットが確実な解決策だったわけではない
Zimaのスタッフは、CMOSをリセットしても改善するかどうかは不明だと明言していました。また、RAID情報はCMOSの外部に保存されているため、BIOSをリセットしても既存のRAID5構成は消去されないとも説明しています。それでも、ストレージのトラブルシューティングでアレイの再作成や再フォーマットにつながる可能性がある操作を行う前には、現在のRAIDリカバリーワークフローを参照する方が安全です。
最も有力な観察結果は、Zima ClientとVPNの相関関係だった
元の投稿者はその後、macOS版Zima Clientを停止してからハングが再発していないと報告し、仕事用VPNが有効なときに障害が起きやすかったようだと述べています。これは因果関係の証明ではありませんが、切り分けに役立つ結果です。
現在のZima Clientの概要では、Zima ClientがZimaOSへの接続経路をどのように作成するかを説明しています。ハングがVPNのルーティングやクライアントと関係しているように見える場合は、両方の変数を同時に変更するのではなく、まずZima Clientを切断した状態で再現し、次にVPNを切断した状態で再現してください。
ホストに接続できなくなる前にネットワークの状態を確認する
コミュニティからの返信では、ソケットの枯渇を確認するよう提案されていました。Linuxのソケット統計では、Linuxでソケット統計やTCPの状態を表示する方法を説明しています。強制再起動後に確認するよりも、システムが応答しなくなる前にソケット数を記録する方が有用です。
別の切り分けとして温度を確認する
別の返信では、過熱の可能性が指摘されていました。Linuxのサーマルフレームワークでは、Linuxのサーマルゾーンと温度インターフェースについて説明しています。ハードロックが起きたからといって過熱だと決めつけず、温度に関する証拠を収集するべきです。
ハングがクライアントやVPNの状況以外でも続く場合は、ZimaOSのインストールトラブルシューティングが、ハードウェアとファームウェアを幅広く確認するためのチェックリストとして役立ちます。
結論
このスレッドでは、ZimaOSのクラッシュを引き起こす原因として確定した単一のバグは特定されませんでした。最も有力な証拠は、ユーザーがmacOS版Zima Clientの使用を停止した後にハングが止まったことであり、VPNの動作がトリガーとして疑われました。クライアントとVPNの相互作用、ソケット、温度、ハードウェアをそれぞれ別の仮説として扱い、最初のトラブルシューティング手順としてストレージをリセットしたりRAIDを再構築したりしないでください。
