（オペレーティングシステム：Debianバリアント）
ゾンビ状態のプロセスです。PPidプロセスに属しますgvim。内容/proc/[pid]/wchanはdo_exit、
/commは以下のようにsh空/cmdlineです。/status
これがバグでしょうかgvim？ Wikipediaのエントリからゾンビプロセスプログラムは自発的に呼び出しを拒否する可能性があると読んでいましたwaitが、これは
gvimかなりの時間アイドル状態のセッションに関するものです。プロセスを終了しましたが、gvimゾンビはまだ周りに隠れています。これはオペレーティングシステムのバグを表しますか？
再びウィキペディアで：
ゾンビプロセスは通常、親プログラムが実行されなくなった場合のオペレーティングシステムのバグを表します。
init放棄されたプロセスはどのくらいの頻度で収集されますか？gvim死んでから少なくとも60分が経ちましたが、まだ残っています。
一方、そうかもしれないshし、そうでないかもしれませんかgvim？
これ/status 文書SigQステータスは0です。
$ 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ではなくそのサブプロセスの1つであるか、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つ以上のプロセスを終了しようとしたからです。
ゾンビは、実際に誰かが興味を持っている場合に備えて、正しくシャットダウンされていないプロセスに関するシャットダウンステータスやその他の情報をオペレーティングシステムが維持する方法です。プロセステーブルのエントリとは別に、ゾンビプロセスはリソースを占有しません（つまり、メモリやCPUを占有しません）。
IMHO、Wikipediaは、収穫されていないゾンビが生成された基本プロセスを終了した後も残っている場合は、オペレーティングシステムのバグを意味すると主張したときに間違っているか、少なくとも誤解を招く可能性があります。ゾンビが両親の死後も生き残ることは珍しいことではなく、この場合init養子になります（PID 1）。 init最終的には収穫されるかもしれませんが、いくつかのゾンビ（initによって採用されたゾンビでも）は再起動するまで残っている可能性があります。プロセステーブルがいっぱいになるほどゾンビプロセスが多くない限り問題になることはほとんどありません。
もちろん、ゾンビは一般的に何かが間違っていることを意味します。つまり、プログラムによって生成されたサブルーチンが親プログラムが予想される前に終了したことを意味します。ただし、問題がオペレーティングシステムである必要はありません。もちろん、これはオペレーティングシステムコンポーネントによって引き起こされる可能性があります。不足または誤って設定されたサウンドサーバーが原因でプログラムのサウンドを処理する必要があるサブプロセスはすぐに終了し、ゾンビのように残ります。
答え4
いつものように、状況によって異なります。ほとんどの監視ツールは、特定の数以上のゾンビプロセスを検出すると黄色または赤に変わります。
したがって、基本的に - はい - これは通常問題の症状です。
しかし、いくつかのプログラムは、「通常の」操作の一部としてゾンビプロセスを作成するのを見ました。その最上位APIが「quit / exit」コマンドを使用して呼び出されると（ここで親プロセスについて話しているわけではありません）、これらのゾンビプロセスは消えます。
したがって、そのような場合、アプリケーションはこれらのゾンビを処理する（そしておそらく必要になるかもしれません）ようです。したがって、監視するには、これらのアプリケーションを実行しているサーバーで例外を定義する必要があります。
他の場合、ゾンビプロセスは短時間で消えるので、ゾンビプロセスは非永続的なシステム状態を持つ可能性があります。
あなたの場合：gvim完了したらゾンビが残ってはいけません。したがって、おそらくバグでしょう。