☰

永続的なゾンビプロセスはバグの兆候ですか?

tag-icon • tag-icon linux process
永続的なゾンビプロセスはバグの兆候ですか?

(OS: Debian バリアント)

ゾンビ状態のプロセスがあります。プロセスPPidに属していますgvim。の内容/proc/[pid]/wchanはdo_exitは 空/commで、以下に示します。sh/cmdline/status

これは のバグでしょうかgvim？Wikipediaのエントリよりゾンビプロセスプログラムが自発的に呼び出しを拒否できると読みましたが、これはかなり長い間アイドル状態だったセッションwaitに対するものでした 。プロセスを閉じましたが、ゾンビはまだ潜んでいます。これは OS のバグを示しているのでしょうか?gvimgvim

再びWikipediaより:

親プログラムが実行されていない場合、ゾンビ プロセスは通常、オペレーティング システムのバグを示します。

そして、Reap はどのくらいの頻度でinitプロセスを停止しますか? が停止してから少なくとも 60 分が経過しましたgvimが、まだ残っています。

一方で、shそうではない可能性もあるでしょうかgvim?

の/status ファイルSigQゼロの状態。

$ less /proc/30339/status
Name     : sh
State    : Z (zombie)
Tgid     : 30339
Pid      : 30339
PPid     : 29673
TracerPid:     0
Uid      :  1000    1000    1000    1000
Gid      :  1000    1000    1000    1000
FDSize   :     0
Groups   :     4 7 20 24 27 29 30 46 107 124 127 1000 
Threads  :     1
SigQ     : 0/30658
SigPnd   : 0000000000000000
ShdPnd   : 0000000000000000
SigBlk   : 0000000000000000
SigIgn   : 0000000000003001
SigCgt   : 0000000000010002
CapInh   : 0000000000000000
CapPrm   : 0000000000000000
CapEff   : 0000000000000000
CapBnd   : ffffffffffffffff
Cpus_allowed     :   3
Cpus_allowed_list:   0-1
Mems_allowed     :   1
Mems_allowed_list:   0
voluntary_ctxt_switches   :   2
nonvoluntary_ctxt_switches:   3

美容睡眠を妨げるわけではないのですが、疑問に思います…

答え1

ゾンビが見られる場合、それを生成したプロセスにバグがあることを示している傾向があります。そのプロセスは、ゾンビを刈り取る ( を呼び出すことによってwait) か、明示的に無視するSIGCLD(またはフラグを設定するSA_NOCLDWAIT) ことになっています。

ただし、これは小さなバグです。ゾンビ プロセスはプロセス テーブル内のエントリを 1 つだけ消費するため、リソースの消費量は無視できるほどです。プロセスが何千ものゾンビを残した場合にのみ、この問題は深刻になります。

ゾンビの親プロセスを終了していません。終了していれば、ゾンビは消えていたはずです。プロセス 29673 (ゾンビの親) はまだ生きていて、活動しています (ただし、実行中ではありませんwait)。これは Gvim ではなく、そのサブプロセスであるか、Gvim ウィンドウを閉じたがプログラムはまだ実行中です。ps l 29673このプロセスが何であるかを確認するには、 を実行してください。

答え2

ゾンビ プロセスが継続的に発生する場合、間違いなく何か問題があると考える傾向があります。ゾンビ プロセスは発生します。職場と自宅の両方で管理しているさまざまなシステムで、通常、月に数回発生します。

通常、これらの問題は、オペレータのエラーまたは特定のソフトウェアの問題が原因で発生します。再起動すると通常は解決し、しばらくは再発しません。

これらが問題となっている場合は、以下を使用して親プロセス ID (PPID) に接続し、gdb何が起こっているかを確認したり、強制終了したりすることができます。

$ gdb -p 100
(gdb) call waitpid(200, 0, 0)
(gdb) quit

もしよろしければ、これらの問題に対処するための他のテクニックについては、以下の追加リソースを読んでみてください。

参考文献

答え3

これは gvim を使用するたびに発生しますか? gvim は、終了時にゾンビを残すこと以外は動作しますか? 実際に問題が起こらない限り、単に無視します。ゾンビはシステムのリソースを消費しません。これが gvim のバグ、またはおそらく gtk のバグであったとしても驚きませんが、プログラムがまったく動作しない限り、無視します。

ゾンビ/機能停止プロセスは、通常、親プロセスが子プロセスを監視開始する前に子プロセスが終了したときに発生します。子プロセスが正常に終了したにもかかわらず、終了ステータスを受け取るプログラムがないため、子プロセスは「そのまま」残ります。そのため、ゾンビになります。ゾンビが発生するもう 1 つの理由は、大規模なプロセス ツリーが崩壊した場合です。おそらく、誰かがツリー内の 1 つ以上のプロセスを強制終了しようとしたためです。

ゾンビは、誰かが興味を持った場合に備えて、正常に終了しなかったプロセスに関する終了ステータスやその他の情報を OS が保持するための方法です。プロセス テーブル内のエントリ以外、ゾンビはリソース (つまり、メモリや CPU) を消費しません。

ウィキペディアは、メインプロセスが終了した後もゾンビが残っている場合、OS のエラーを意味すると主張していますが、これは私の意見では間違っています (少なくとも誤解しやすいです)。ゾンビが親を生き延びて、その場合はinit(PID 1) に引き取られることは珍しくありません。 init最終的にはゾンビが引き取られるかもしれませんが、一部のゾンビは (init に引き取られたものでも) 再起動するまで残る可能性があります。プロセス テーブルを埋め尽くすほどゾンビが多すぎない限り、ほとんど問題にはなりません。

もちろん、ゾンビは何かが間違っていることを示している場合が多いです。つまり、プログラムが子プロセスを生み出し、それが親プロセスが期待するよりも早く終了するということです。しかし、問題が OS である必要はありません。ただし、OS コンポーネントが原因である可能性は確かにあります。たとえば、サウンド サーバーが欠落しているか、正しく構成されていないと、プログラムのサウンドを処理するはずの子プロセスがすぐに終了し、ゾンビとして残ります。

答え4

いつものように、それは状況によります。ほとんどの監視ツールは、一定数を超えるゾンビプロセスに遭遇すると、黄色または赤に変わります。

つまり、基本的には、はい、それは通常、問題の兆候です。

しかし、私は「通常の」操作の一環としてゾンビプロセスを生成するプログラムを見たことがあります。これらのゾンビプロセスは、対応するトップレベル API (ここでは親プロセスとは言いません) が「quit/exit」コマンドで呼び出されたときに消えました。

したがって、これらのケースでは、アプリケーションがこれらのゾンビを処理した (そしておそらく必要とした) ようです。そのため、監視のために、これらのアプリケーションが実行されているサーバーで例外を定義する必要がありました。

他のケースでは、ゾンビは短時間で消えたため、ゾンビ プロセスによって特定の非永続的なシステム状態が発生する可能性があります。

あなたの場合:gvim完了すると、ゾンビは残らないはずです。おそらくバグです。

関連情報