ファイアウォールの背後にあるNFS共有によって、プロセスがD状態に停止している問題がしばしば発生します。接続が失われると、プロセスはD状態になり、終了できません。唯一の解決策はハード再起動です。他の方法がないかと悩んでいましたが、私が見つけた解決策と情報はすべて「ただ殺すことはできません」というだけでした。誰もが現状の維持を受け入れて受け入れるようです。私はこれについてやや批判的です。プロセスを再起動する必要がないように、メモリからプロセスを掻き取る方法が必要だと思います。このようなことが頻繁に発生すると、非常に迷惑になることができます。リソースがIOを返す場合、この場合は単に無視できます。なぜこれは不可能ですか？ IMHO、Linuxカーネルは非常に進歩しているので、このようなことができるはずです。特にサーバーでは...
満足のいく答えが見つかりません。なぜ実装されていないか実装できないのですか？
私はまた、この質問を説明できるプログラミングとアルゴリズムの性質への答えにも興味があります。
答え1
システムコールでプロセスを終了することができ、ほとんどの場合動作します。難しい部分は常に動作するようにすることです。 99.99％から100％に行くのは難しい部分です。
通常、プロセスが終了すると、そのプロセスで使用されているすべてのリソースが解放されます。プロセスで入出力が進行中の場合、入出力を実行するコードに通知が送信され、終了し、使用中のリソースが解放されます。
中断されないスリープモードは、「コードが通知され終了する」のに無視できない時間がかかると顕著に発生します。これは、コードが正しく機能しないことを意味します。これは間違いです。はい、理論的にはバグのないコードを書くことは可能ですが、実際には不可能です。
「リソースがIOを返す場合は、単に無視できます」と言います。わかりました。ただし、周辺機器が次のようにプログラムされていると仮定します。メモリへの書き込みプロセスに属します。周辺機器への要求をキャンセルせずにプロセスを終了するには、メモリ使用量を何とか維持する必要があります。リソースを直接削除することはできません。一部のリソースはあなたに残る必要があります。カーネルがどのリソースを解放しても安全かどうかを知っている場合にのみ、他のリソースを解放できます。これを行うには、常に区別できる方法でコードを書く必要があります。邪魔にならない睡眠がかなりの時間持続する状況は判断できず、唯一の安全な方法はこれを避けることです。
シャットダウンプロセスが機能することを保証するオペレーティングシステムを設計することが可能です（ハードウェアが正しく動作するという特定の前提の下で）。たとえば、ハードリアルタイムオペレーティングシステムは、プロセスの終了に最大の特定の固定時間がかかることを保証します（終了機能を提供すると仮定）。しかし、これは難しいことであり、特にオペレーティングシステムが広範囲の周辺機器をサポートし、優れた共通性能を提供する必要がある場合にはさらにそうです。 Linuxは、多くの点で最悪の動作よりも一般的な動作を好みます。
すべてのコードパスをカバーするのは非常に難しいです。特に、最初の日からこれを行うための厳しいフレームワークがない場合は、さらにそうです。全体的に、終了できないプロセスは非常にまれです。発生しない場合は不明です。これはオフロード車の運転手の症状です。 Linuxドライバの作成には限られた労力がかかりました。長期間中断することなく眠りに落ちる場合をさらに排除するには、作業を実行するためにもっと多くの人が必要になるか、ハードウェアのサポートが減り、パフォーマンスが低下します。