私はVirtualBoxプロセスをぶら下げて、それを強制終了しようとしましたが(KILL
/ABORT
)、成功しませんでした。親pidは1(初期)です。
top
は、プロセスをD
として示します。これは、「無停電スリープ」として文書化されています。
strace
は何も表示されません。
どうすればこれを取り除くことができますか?これにより、VirtualBoxカーネルドライバーをアンロードして新しいドライバーをロードできなくなります。
簡単な答え:できません。
より長い答え:中断のないスリープは、プロセスがシグナルによって起こされないことを意味します。それはそれが待っているものによってのみ起こされることができます。私がそのような状況になったとき。 CD-ROMでは、通常、suspend-to-diskを使用してコンピューターをリセットし、再開します。
無停止プロセスの強制終了は成功しますが、すぐには実行されません。プロセスは、実際にシグナルを受信するまで消えません。したがって、シグナルを送信するだけではプロセスを取り除くのに十分ではなく、無停止のスリープからシグナルをウェイクアップする必要もあります。
Tanel Poderは素晴らしい D状態プロセスを分析するためのガイド を書いています。この状態が不完全なI/Oによって引き起こされることは非常に一般的です。ネットワーク障害。 slmはいくつかの スーパーユーザーの非常に便利なポインタ ネットワークI/Oを妨害解除する方法、および問題自体を投稿しました。
個人的には、VirtualBoxでWindowsを処理するとき、およびワインを処理するときでも、cdrom I/Oが完了しないためにこの問題によく遭遇します(ある種のディスク存在チェックだと思います)。 ATAデバイスはリセットできます 、これはプロセスを妨害しそうです。たとえば、次の小さなスクリプトを使用して両方のオプティカルドライブをリセットし、それらがブロックしているプロセスを妨害していません。
echo 1 > /sys/block/sr0/delete
echo 1 > /sys/block/sr1/delete
echo "- - -" > /sys/class/scsi_Host/host7/scan
D状態は基本的に、プロセスがディスクI/O、または中断できない他のブロックI/Oを待っていることを意味します。これは、カーネルまたはデバイスが熱心に(特に光ディスクから)不良ブロックを読み取ろうとしていることを意味します。時々それは何か他のものがあることを意味します。
プロセスは、D状態が解除されるまで強制終了できません。それが待っているものを見つけ、それを修正してください。簡単な方法は再起動することです。問題のディスクを削除することで解決する場合もありますが、それはかなり危険な場合があります。何をしているのかわからない場合、修復不可能な壊滅的なハードウェア障害です(読み:煙が出てくる)。
最近、リモートサーバーでD
状態のプロセスに遭遇しました。プロセスを削除するにはハードリブートまたは電源の再投入が必要であることを明確にしたいと思います。
他のすべてのオプションを使い果たすまで、ソフトリブートを試行しないでください。たとえば、プロセスがハングしているリソースを解放してみることができます。ソフトリブートでは、システムが部分的にシャットダウンされ、sshに応答しなくなる可能性がありますが、無停止プロセスを終了しようとしてハングしているため、リブートしません。
他の人が言ったように、割り込み不可能なプロセスは、割り込みできないカーネル関数でスタックしているプロセスです(通常、何らかのI/O操作を待機しています)。詳細な説明については this answer を参照してください。
コンピューターの再起動とは別に、いくつかのプロセスをD
状態から flushing linux VM caches :
kill -9 {process_id}
sync
echo 3 | Sudo tee /proc/sys/vm/drop_caches
これはシステムの安定性に影響を与えていないようですが、私はシステムプログラマではないため、これが予期しない結果をもたらす可能性があるかどうかはわかりません。
編集:
kernel docs によると、drop_caches
は、開発環境ではかなり安全なようです。
drop_caches
これに書き込むと、カーネルはクリーンなキャッシュだけでなく、デントリやiノードなどの再利用可能なスラブオブジェクトも削除します。ドロップすると、メモリは解放されます。
ページキャッシュを解放するには:
echo 1 > /proc/sys/vm/drop_caches
再利用可能なスラブオブジェクト(エントリとiノードを含む)を解放するには:
echo 2 > /proc/sys/vm/drop_caches
スラブオブジェクトとページキャッシュを解放するには:
echo 3 > /proc/sys/vm/drop_caches
これは非破壊的な操作であり、ダーティオブジェクトを解放しません。この操作で解放されるオブジェクトの数を増やすには、/ proc/sys/vm/drop_cachesに書き込む前に「sync」を実行します。これにより、システム上のダーティオブジェクトの数が最小限に抑えられ、削除する候補がさらに作成されます。
このファイルは、さまざまなカーネルキャッシュ(inode、dentries、pagecacheなど)の増大を制御する手段ではありません。これらのオブジェクトは、システムの他の場所でメモリが必要になったときに、カーネルによって自動的に再利用されます。
このファイルを使用すると、パフォーマンスの問題が発生する可能性があります。キャッシュされたオブジェクトを破棄するため、特に頻繁に使用されている場合は、削除されたオブジェクトを再作成するために大量のI/OとCPUを消費する可能性があります。このため、テストまたはデバッグ環境以外での使用はお勧めしません。
このファイルを使用すると、カーネルログに情報メッセージが表示される場合があります。
cat (1234): drop_caches: 3
これらは情報提供のみを目的としています。システムに問題があるという意味ではありません。それらを無効にするには、4(ビット3)をdrop_cachesにエコーします。
ここでは新しく、経験はありませんが、htopを使用してステータスを確認すると、プロセスが無停電スリープ(D状態)になるのと同じ問題がありました。何らかの理由で、
kill -9 <pid>
私のために働いた。多分同じことを試すことができます。
編集:ostrokachが詳細な回答を用意しています(私にはわかりませんでした)。