ゾンビプロセスとは何ですか？
ゾンビプロセスは、タスクを終了したプロセスですが、親プロセス（ほとんどの場合）が予期せずに停止またはクラッシュしました。また、バグのあるコードを示している可能性もあります。ほとんどのユーザーは、ゾンビプロセスとは何か、およびそれらがLinuxホストにどのように影響するかをよく理解していません。何よりもまず、ゾンビプロセスの数が少ない（たとえば10）場合、システムの負荷には影響しません。実際、何千ものゾンビはシステムの負荷に寄与しません。
定義上、ゾンビプロセスはほとんどの場合リソースを消費しません。各ゾンビプロセスには、プロセスID番号（PID）が引き続き割り当てられます。 32ビットシステムでは、使用可能なPIDの最大数は32767です。64ビットシステムの場合、その数は指数関数的に400万を超えます。
各ゾンビプロセスに使用される少量のメモリもあります。技術的には、システムリソースを大幅に使い果たすには、数万、場合によっては数十万のゾンビプロセスが必要になります。
ここで説明するシナリオは2つあります。 1つ目は、多数の子PIDを生成するプロセスであり、次に、親PIDがクラッシュするか、子PIDを取得せずに停止します。通常、この問題は、プログラムまたはコードにバグがある可能性があることを示しています。これが発生すると、PID 1（またはinitプロセス）がそれらの所有権を取得します。このハウツーの目的のために、これらのゾンビを取り除くための最も速い道は再起動することです。ダミープロセスを作成し、それらのゾンビプロセスの所有権をダミーPIDに戻してクリーンアップすることもできます。それはここでは範囲外です。再起動して完了です！
2番目のシナリオは、OSがプロセスを実行していると見なすまでプロセスがハングしているが、プロセスが実際には何もしていない場合です。このディスカッションで使用している例は、自動バグ報告ツールデーモン（abrtd）です。 ）Red HatEnterpriseLinuxおよびその他のディストリビューションに同梱されています。これは優れたツールであり、システム管理者として、クラッシュカーネルを呼び出さずに、何が起こっているのか、またはクラッシュしているのかをよりよく把握できるため、システム上で稼働させるのが好きです。
私の環境では、このデーモンも少しアキレス腱です。デフォルトでは、abrtd 署名されたアプリケーションの情報のみを作成します。どのアプリにも署名してバグを生成できますが、署名されていないアプリがabrtdをトリガーした場合 、デーモンはバグレポートを作成する動作を実行し、作成したものをすべて削除します。この動作により、署名されていないアプリのアクションがハングするという問題が発生する可能性があります。
例を見てみましょう。ユーザーは、6つのゾンビプロセスが原因でシステムが低速であるというインシデントレポートを送信します。 abrtdのシステムにはいくつかの死んだ景品があります 問題があります。 su -の場合 ルートするには、次のように表示されます：
'abrt-cli status' timed out
abrtdを確認すると プロセスはまだ実行されていることがわかりますが、5/30以降に実行されている子プロセスがあります。
[root@$HOSTNAME ~]# systemctl status abrtd
● abrtd.service - ABRT Automated Bug Reporting Tool
Loaded: loaded (/usr/lib/systemd/system/abrtd.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2019-04-27 08:36:47 EDT; 2 months 13 days ago
Main PID: 1161 (abrtd)
Tasks: 12
Memory: 34.0M
CGroup: /system.slice/abrtd.service
├─ 1161 /usr/sbin/abrtd -d -s
├─60777 abrt-server -s
├─60867 /usr/libexec/abrt-handle-event -i -e post-create -- /var/spool/abrt/unsigned-app-2019-05-30-01:48:24-57451
├─64714 abrt-server -s
├─68157 abrt-server -s
├─70725 abrt-server -s
├─74101 abrt-server -s
├─77136 abrt-server -s
├─81417 abrt-server -s
├─84637 abrt-server -s
├─88183 abrt-server -s
└─90022 abrt-server -s
したがって、abrtd はまだ技術的には実行されていますが、その作成後のプロセスにより、いくつかの新しいABRTクラッシュレポートを実行しようとしたが、ゾンビに変わった状態が作成されました。この時点で、abrtdを再起動できます サービス、およびそのアクションはすべてのゾンビプロセスをクリアします。
ただし、それが事実であることがわからない場合は、ps -xalを使用して、ゾンビの親であるPIDを追跡する方法を次に示します。 指図。このコマンドはロットを出力します の情報があるので、必要な列を表示します：
[root@$HOSTNAME ~]# ps -xal | awk '{ print $4 " " $10 " " $13 }' | sort -n
1739 Ssl+ java
1903 S bin/rscd
1903 S bin/rscd
2391 Ssl+ node
2816 Ssl+ java
2889 Ssl+ java
3785 Ss appcollect
3785 Ss appconfigcollect
3926 Ssl+ java
4696 Ss /bin/sh
4731 S bin/bash
4827 Sl /myappbinaries/jre/bin/java
7074 Ss+ httpd
7095 S+ httpd
4番目の列は親のPID、10番目の列は子プロセスのステータス（明らかにZ状態のPIDを探している）、13番目の列は子プロセスです。 4列目の親PIDを使用すると、その親プロセスを強制終了でき、ゾンビの子も削除されます。その親PIDが1でない限り、その場合は再起動が必要になります。
運用中のため、いつでも再起動できるとは限りません。個人的には、再起動が最後の手段になると思います。再起動すると、多数の罪が隠され、それらの罪は、通常は深夜や休日の週末など、最も不適切な時間に現れるようになります。
ああ、abrtdを再起動した後、このシステムの負荷は1ビット低下しませんでした そしてそれらの6つのゾンビをクリアします。