影響を受けるシステムはvSphereで実行されている仮想マシンであり、本番サーバーであるため、問題が表面化しても通常はトラブルシューティング時間はありません。再起動後の問題はなくなり、一週間ほど経過するとシステムが安定して戻っているようでした。このようなことが再び起こったら、何をすべきか、それを見つけるべきかについていくつかのアイデアを探しています（現在のパターンが本当なら、おそらく今週の木曜日か金曜日の頃）。
VMはpingにうまく応答しますが、まだ聞くhttp / sリクエスト（apache2）に使用されますが、応答しません。また、SSH を受信しますが、セッションを閉じる前に認証を求めるプロンプトは表示されません。
コマンドを送信すると、「ローカル」コンソールはすぐに中断されます。それまでは、システムに要求している場合にのみ必要なものを入力できます。する動作が停止しました。これには、ファイル名などにタブ補完機能を使用する試みが含まれます。他の仮想端末の1つに切り替えてユーザー名とパスワードを入力できますが...システムは再び停止します。
/var/logのログには競合に関する情報はありません（他の場所を見るためのポインタはありますか？）。ログファイルの最後のメッセージは、実際の問題が発生する前に記録されました。
追加情報：
この問題が発生すると、仮想マシンのローカルコンソールに何も印刷されません。仮想マシンには、LSI Logic Parallel vSCSIを介して接続された1TBボリューム（シックプロビジョニング、遅延ゼロ化）があります。データストア自体は、他のいくつかのESXiホストにもサービスを提供する大規模NASであり、このような状況が発生しても他のゲストは影響を受けません。
この問題が発生すると、vCenter / vSphereは異常に高いCPUまたはメモリ使用率を表示しません。
少なくとも一度は、SFTPを介してサーバーにアクセスしようとする誰かがそれを発見するまで8時間以上続くことがありました。
sourcejediの提案に従って、コンソールログのしきい値を5に下げ、仮想マシンのローカルコンソールから/ dev / kmsgに送信されたメッセージを表示できることを確認しました。変更する前に、これらのメッセージは表示されなかったので、カーネルは何かを話そうとしましたが、見たことがないかもしれません。
ESXiホストに無料のリソースがあるため、VMも複製して別々の孤立したネットワークに配置しました。この問題が発生すると、その過程で生産サービスが中断されることを心配することなく、問題を解決するのに時間がかかります。
より多くの情報が出たら更新します。これまで助けてくれた皆さんに感謝します！
答え1
- 仮説
- 指示する
- 愚かなハッキング（作業がファイルシステム/ディスクアクセスによって中断されると仮定）
1. 仮定
1.1）デフォルトでは、Linuxカーネルにはさまざまな種類の競合または中断を報告するコードがあります。
どちらも現在の問題を表示し、「ローカルコンソール」に呼び出しチェーンを印刷します。根本的な原因を明らかにすることはできません。このコードは決して100％信頼できません。しかし、通常は何かを得ることになり、何もないよりもはるかに優れています。
したがって、コンソールでこれらのカーネルログメッセージを表示できることを再確認する必要があります。詳細については、次のセクションで確認してください。
1.2）カーネル自体は依然としてキーストロークとネットワークパケットに応答しているので、保留中のジョブディテクタがここで機能したいと思います。
カーネルスレッドと割り込みはまだ実行中のように聞こえますが、ユーザースペースプロセスは停止します。これらの症状は、プロセスが物理ファイルシステムにアクセスしようとしたときに中断されることと一致します。プロセスが数分間停止すると、カーネルは「保留中のジョブ」メッセージと呼び出しチェーンを印刷します。
1.3) また、ユーザープロセスは完全に一時停止されていませんが、非常にゆっくり、そして彼らが成長するのを見るのに十分なほど「十分に長い」待たないでください。
メカニカルHDDを搭載したLinux PCを使ったことがある場合は、この話に精通しています。 :-).しかし、これは机の上のPCではないため、騒々しいハードドライブや恒久的に点灯しているディスクアクティビティインジケータに気づかないでしょう:-)。
私はサーバー管理の経験がありません。しかし、これらの問題を検出するには監視ソフトウェアを使用する必要があると思います。理想的には、ユーザーに目立つ問題が発生する前でもそうです。
たとえば、システムメモリ使用量を監視すると、徐々に「メモリリーク」が発生し、システムがシャットダウンするまで自己交換を開始することを確認できます。この問題が発生しないことを願っています。たとえば、login交換すると、コンソールのログイン速度が遅くなったり、パスワードの入力を求められます。
十分にきめ細かい監視がある場合は、観察されたエラーが発生する前にディスクIO秒の増加を検出できます。
2. 使用説明書
2.1) カーネルパニックが印刷されているかどうかを知るために、「ローカルコンソール」が記録されるか、少なくとも持続しますか？実際はそうですが、シミュレートされたvSphereなどを使用すると、どのように機能するのかわかりません。TVシリーズ快適。アナログビデオディスプレイのみを使用している場合は、すでに持続する状態です。
このVMWare記事同じ仮定に頼っているようです。
2.2) コンソールロギングを無効にしていないことを確認してください。 次のコマンドを実行します。
sudo sh -c "echo '<3>test' >/dev/kmsg"
コンソールに「テスト」と表示する必要があります。以下でスタックトレースについて説明する内容もご覧ください。
シミュレートされたビデオディスプレイの場合、一部の競合メッセージが画面上部でスクロールして消えることがあります。カーネルにある場合墜落、Shift + PageUpを使用して上にスクロールすることはできません。原則として、ロールバックを実装するエミュレートされたシリアルコンソールを持つ方が便利です。
カーネルパニックの場合、上記のVMWareリンクにいくつかの異なるクラッシュダンプ提案があります。
2.3）パスワードを入力した後に停止する現象は、ディスクが応答しないように聞こえます。私の考えでは、Linux SCSI操作が時間が経過するとタイムアウトが発生し、タイムアウトがカーネルエラーとして記録されるため、Linuxはコンソールに印刷するようです。 ファイルシステムはSCSIプロトコルまたは他のプロトコルを使用してマウントされていますか？
2.4）デフォルトでは、カーネルは保留中のジョブを検出し、次のメッセージを印刷しますtask bash:999 blocked for more than 120 seconds。以下は呼び出しチェーン（「スタックトレース」）です。それでも、コールチェーン部分はカーネルの「デフォルトログレベル」を使用して記録されているようですが、これは通常レベル4（警告）を意味します。
保留中のジョブメッセージの呼び出しチェーン部分を表示するには、コンソールログレベルを上げる必要があります。以上たとえば、レベル4 dmesg -n 5。
保留中のジョブメッセージを無効にしていないことを確認するには： cat /proc/sys/kernel/hung_task_timeout_secsたとえば、正数を表示する必要があります120。
保留中のジョブメッセージを印刷しないネットワークファイルシステムがハングします。。 保留中のジョブは、「中断できず」「終了できない」場合にのみ印刷されます。 NFSで停止したプロセスが終了する可能性がある。このような中断を引き起こす可能性があるネットワークファイルシステムを使用している場合は、この点を考慮した可能性があります。 （そしてどういうわけかNFSサーバーへの接続をテストする代わりにただテスト中断されたVMを使用するpingと、質問にはこのすべてが含まれます。 :-). NFS サーバーが別の VM に応答しているように見えるが、この VM に保留中のジョブ メッセージが表示されない場合は、sysrq+T を使用して調べることができます (下記参照)。
保留中のジョブメッセージは、Debian Linuxバージョンでデフォルトで有効になっています。 （何らかの理由で私のFedora Linuxカーネルにはビルド時に保留ジョブ検出器はまったく含まれていません。RHELおよびSLESカーネルに含まれているように見えますが、FIXME）。
ハングしたジョブメッセージを検索したとき、ハングしたサーバーとIOエラーメッセージが共通のトピックであるように見えました。 :-).
そしてLinux sysrq。シリアルコンソールがありますが、接続後にのみ印刷された出力をキャプチャできる場合は、sysrq + Tを使用して保留中のジョブを参照できます。これにより、次の情報がダンプされます。すべてシステムの仕事なのでたくさんコンソールに出力します。したがって、コンソールがビデオモニターの場合、これはあまり役に立ちません。そして、稼働中の本番システムでテストしないでください。一部のディストリビューションでは、sysrq物理的なセキュリティ上の理由からデフォルトで無効にします。 Debian はsysrqアクティブなままです。もちろん、セキュリティチェックリストを使用してを無効にするように指示した可能性がありますsysrq。
2.4）元の質問は、観察されたエラーの前に、またはシステムが頻繁に過負荷になっていないことを示すために「応答性」の定量的モニタリングを引用しません（最終的な拡張かもしれません）。
様々なサービスのサービス「応答性」の定量的モニタリングの価値を考える。これには、SSH サーバーへのログインを含めることができます。システム利用レベル、待ち時間、1秒あたりのネットワークパケットもあります。
PS両方ディスク輻輳%そして「CPU待機」呪われるかもしれません。また、現在のディスクレイテンシとIOPSを監視したいと思います。 （しかし、現在Debian 9.xカーネルはディスク使用率に比較的敏感でなければなりません）。
上記の回答とVMwareリンクは、知っておくべきか少なくとも存在することを知る必要があるいくつかの標準ツールについて説明します。
3.愚かなハッキング（作業がファイルシステム/ディスクアクセスによって中断されると仮定）
以下の詳細は愚かなハッキングです。時々あなたが必要とするのは愚かなハッカーだけです。私はあなたがこれに頼る必要があるならば、おそらくあなたがやっている方法に対処しなければならないいくつかの欠陥があることを示していると言うでしょう。 ：-P。
システムが「準応答」状態のときに実行したいいくつかのシェルテストがある場合は、mlock（）のbusyboxシェルを実行してみてください。例えばいいえ静的に接続されたビジボックスの使用このLD_PRELOAD mlockハッカー。次に、(exec -a ls /proc/self/exe /)たとえばbusyboxコマンドを実行します。おそらく最も安全な方法は次のとおりです。
# prevent you running any normal program by mistake!
OLDPATH="$PATH"
PATH=
# run a busybox builtin
b() (
local command="$1"
shift
exec -a "$command" /proc/self/exe "$@"
)
# run normal program in the background, in case it hangs
p() {
local PATH="$OLDPATH"
exec "$@" &
}
b dmesgこれにより、キャッシュされていないファイルを読み取ることなく実行できます。
（誰かが1）中断されたファイルシステムのマウントを管理し、2）中断されずにアクセスできないように/マウントすると、これが問題になります。私はこれが可能性が低く、防御するのがより痛いと思います。 )/proc/proc
b ps -o stat,pid,argsプロセスのステータスが表示されます。Dこれは「中断されていない状態」を意味します。通常、ディスクまたはネットワークファイルシステムを待っています。これにより、b cat /proc/999/stackPID 999がカーネルで待機している場所が表示されます。
cd /sys/class/block/ && b grep -H . */inflight各ディスクに対して進行中の読み取りおよび書き込みの数が表示されます。