なぜ無停止D状態プロセスを強制終了できないのですか？
ファイアウォールの背後にあるNFS共有が原因で、プロセスがD状態でスタックする問題がよくあります。接続が失われると、プロセスがD状態のままになり、プロセスを強制終了できません。唯一の解決策はハードリブートになります。他に方法はないかと思っていましたが、見つけることができるすべての解決策と情報は「あなたはそれを殺すことはできない」です。だれもが元気で、それを受け入れるようです。私はこれについて少し批判的です。再起動の必要がないように、メモリからプロセスを削り取る方法が必要だと思いました。これが頻繁に発生する場合、それは非常に迷惑です。そして、リソースがたまたまIOを返す場合、この場合は単に無視できます。なぜこれができないのですか？ Linuxカーネルは非常に高度なIMHOであり、このようなことができるはずです。特にサーバーでは...
満足のいく答えを見つけることができませんでした。なぜこれを実装できない/できないのですか？
この問題を説明するプログラミングとアルゴリズムの性質に関する回答にも興味があります。
システムコール中にプロセスを強制終了することは可能であり、ほとんどの場合機能します。難しいのは、常に機能させることです。 99.99％から100％にするのは難しい部分です。
通常、プロセスが強制終了されると、そのプロセスが使用するすべてのリソースが解放されます。プロセスでI/Oが進行中の場合、このI/Oを実行するコードに通知されて終了し、使用中のリソースを解放できるようになります。
「コードに通知されて終了する」時間が無視できないほどの時間がかかると、無停電スリープが目に見えて発生します。つまり、コードは正常に機能していません。それはバグです。はい、バグなしでコードを書くことは理論的には可能ですが、実際には不可能です。
「リソースがたまたまIOを返す場合、それは単に無視できます」と言います。まあ、元気です。しかし、たとえば、ペリフェラルがプロセスに属する メモリへの書き込み にプログラムされているとします。周辺機器へのリクエストをキャンセルせずにプロセスを強制終了するには、メモリを何らかの方法で使用し続ける必要があります。そのリソースを単に取り除くことはできません。留まらなければならないリソースがあります。また、他のリソースの解放は、カーネルが解放しても安全なリソースを知っている場合にのみ実行できます。これには、常に通知できるようにコードを記述する必要があります。中断のない睡眠が目に見える時間続く場合は、それを伝えることが不可能である場合であり、唯一の安全な方法は方法です。
プロセスの強制終了が機能することが保証されているオペレーティングシステムを設計することは可能です（ハードウェアが正しく機能しているという特定の前提の下で）。たとえば、ハードリアルタイムオペレーティングシステムは、プロセスの強制終了に最大で一定の時間がかかることを保証します（プロセスが強制終了機能を提供している場合）。ただし、特にオペレーティングシステムが幅広い周辺機器をサポートし、一般的なケースで優れたパフォーマンスを提供する必要がある場合は、特に困難です。 Linuxは、多くの点で、ワーストケースの動作よりもコモンケースの動作を優先しています。
すべてのコードパスをカバーすることは非常に困難です。特に、1日目からそうするための厳しいフレームワークがなかった場合は、大雑把な計画では、殺せないプロセスは非常にまれです（それらが起こらなくても気付かないでしょう）。 ）。バグのあるドライバーの症状です。 Linuxドライバーの作成には、限られた労力が費やされています。中断のない長時間の睡眠のケースを減らすには、タスクに必要な人員が増えるか、サポートされるハードウェアが少なくなり、パフォーマンスが低下します。