Linuxでは、子プロセスが終了し、その親プロセスがまだそれを待っていない場合は、ゾンビプロセスになります。子プロセスの終了コードは pid 記述子に格納されます。
a がSIGKILL子に送信されると、何の効果もありません。
これは、SIGKILL終了コードが変更されないことを意味しますか、それとも終了コードが変更され、子プロセスが終了したことを示すために変更されることを意味しますかSIGKILL？
ベストアンサー1
この質問に答えるには、信号がプロセスに送信される方法と、プロセスがカーネルにどのように存在するかを理解する必要があります。
task_struct各プロセスは、カーネルによって内部的にsched.hヘッダファイルに定義されて開始されます。ここ）。この構造は、pidなどのプロセスに関する情報を保持します。重要な情報は次の場所にあります。1566ライン関連信号が保存される場所です。この値は、信号がプロセスに送信されるときにのみ設定されます。
死んだプロセスやゾンビプロセスにはまだtask_struct。この構造は、親プロセス（自然または養子縁組）がwait()受信後にSIGCHLD子供の獲得を要求するまで維持されます。信号が送信されるとsignal_struct設定されます。この場合、信号を捕捉できるかどうかは重要ではありません。
信号は、プロセスが実行されるたびに評価されます。または正確に言えば、今後プロセス会議ランニング。その後、プロセスはTASK_RUNNING状態になります。カーネルは、schedule()スケジューリングアルゴリズムに基づいて実行する次のプロセスを決定するルーチンを実行します。そのプロセスが次の実行プロセスであると仮定し、処理するsignal_struct待機信号があるかどうかを判断するために値を評価します。シグナルハンドラを手動で定義した場合（次を介して）signal()またはsigaction()）、そうでない場合は登録された機能を実行します。信号の基本動作処刑される。デフォルトの動作は送信される信号によって異なります。
たとえば、シグナルのデフォルトハンドラSIGSTOPは、現在のプロセスの状態を変更し、TASK_STOPPED実行schedule()する新しいプロセスを選択するために実行されます。はSIGSTOPキャプチャできないため（たとえばSIGKILL）、手動シグナルハンドラを登録できません。信号を捕捉できない場合は、常に基本的な操作が行われます。
あなたの質問について：
スケジューラは、デッドプロセスまたはデッドプロセスがTASK_RUNNING再びその状態にあるかどうかを確認しません。したがって、カーネルは、信号が何であるかに関係なく、その信号に対してシグナルハンドラ（デフォルトまたは定義済み）を実行しません。だからexit_signal再び設定されません。シグナルは in を設定してsignal_structプロセスに「転送」されますが、task_structプロセスが再実行されないため、何も起こりません。実行するコードがなく、プロセスに残っているのはプロセス構造です。
ただし、親プロセスが子プロセスを収集する場合、wait()受信される終了コードは、プロセスが「元の」終了したときに持っていた終了コードです。処理待機中の信号があるかどうかは重要ではありません。