暴走が原因でマシンがハングしたかどうかを示すログがSuSeLinuxにありますか？
不明な問題が原因でハングしているSuSeLinuxサーバーがあります。時々実行されている暴走プロセスがあり、それがハングの原因になっているのではないかと考えています。
問題は、ハングが発生した後、どこでそれを探すべきかわからないということです...（暴走を見つけるために一日中上を見て過ごしたくない）-だから私の質問はこれです：何かありますか暴走を記録するSuSeにログインしますか？そうでない場合、そのようなものをログに記録する方法はありますか？
どうもありがとう！
より多くの情報が役立ちます。 「ハング」をどのように定義していますか？サーバーに物理的にアクセスできる場合は、ハングした後に画面に表示されるカーネルメッセージを確認できます。サーバーが停止した後、サーバーを再起動する必要がありますか？
/ var/log/messagesで、クラッシュの時点までの通常のシステムログを追跡できます。サーバーが停止したときに開いているセッションがある場合は、dmesgを実行してドライバーメッセージを確認します。
ハードウェアの詳細はありますか？これがサーバーグレードのハードウェアである場合は、システムのハードウェアログをチェックして、RAMの不良などの問題があるかどうかを確認できる場合があります。
いいえ、一般的に、何が「ハング」を引き起こしたのかを正確に伝えるメカニズムはありません。
マシンの実行中に、topを使用してCPUを過剰に消費しているプロセスを探し、freeを使用してメモリの問題をチェックし（ディスクにスワップするとマシンが非常に遅くなる可能性があります）、/ varを調べます。/logスキミングファイルを使用して、問題がないかどうかを確認します。
ps aux | grep Zゾンビプロセスがある場合は、それらを除外します。
サーバーがフリーズするSuSEのケースをオープンしました。彼らはこれらのステップを推奨しました：
- シリアルコンソールを接続すると（フリーズにはあまり興味がありません）、iLOを取得しました...
- Syslogをリモートマシンにリダイレクトします（「有名な最後の言葉」が表示されるように、おそらく元のシステムが/ var/log/messagesに同期する直前）
- KDUMP-Kernelとdebug-kernelをインストールします（フリーズではなくkernel-oopsを取得する機会を与えます）
最後は私の場合に役立ちました-しかし、特定のアクションをトリガーすることで問題を再認識できました-その後、フリーズの直前にカーネルデバッグを取得し、SuSEがPTF（ポイントツーフィックス）を提供することができました問題を取り除いたカーネル。
しかし、それでもあなたはあなたの問題がどのような状況で発生するのかを説明していませんでした-真夜中に？仕事中にはありませんか？