私はUbuntu 14.04を使用していますが、理解できないように見えるこの現象が発生しています。

1. yesコマンドを実行します（デフォルトのシェル：Bashで）
2. 入力CtrlZして停止yes
3. を実行しますjobs。出力：
   [1]+ Stopped yes
4. 実行kill -9 %1して停止しyesます。出力：
   [1]+ Stopped yes
5. を実行しますjobs。出力：
   [1]+ Stopped yes

これは3.16.0-30-generic、Parallels仮想マシンで実行されているUbuntuにあります。

kill -9コマンドでyesコマンドが終了しなかったのはなぜですか？SIGKILLを捕まえることも無視することもできないと思いましたか？そして、どうすればyesコマンドを終了できますか？

中断されたプロセスのシグナルはブロックされます。ターミナルで：

$ yes
...
y
y
^Zy

[1]+  Stopped                 yes

2番目のターミナル：

$ killall yes

最初のターミナルで：

$ jobs
[1]+  Stopped                 yes

$ fg
yes
Terminated

ただしSIGKILL、ブロックすることはできません。killall -9 yes2番目の端末から同じことを行うと、すぐに次のようになりyesます：

[1]+  Killed                  yes

したがってkill -9 %1、プロセスがすぐに終了しない場合は、プロセスが終了するbashまで実際に信号を送信していないかfg、カーネルのバグを発見していることになります。

慌てる必要はありません。

ファンキーなことは何も起こっていません。ここにはカーネルのバグはありません。これは、Bourne Againシェルおよびマルチタスクオペレーティングシステムからの完全に正常な動作です。

覚えておかなければならないのは、プロセスがに応答してもそれ自体を殺すことSIGKILLです。ここで起こっているのは、Bourne Againシェルが、自分自身を殺すように言ったプロセスが自分自身を殺すために取り掛かる前に、物事を回避しているということです。

でyes停止し、Bourne AgainシェルでコマンドをSIGTSTP実行したところから何が起こるかを考えkillます。

1. シェルSIGKILLはyesプロセスに送信します。
2. 並行して：
   1. yesプロセスが実行するようにスケジュールし、すぐに自分自身を殺しています。
   2. Bourne Againシェルは続行し、別のプロンプトを出します。

あるものを見て他の人が別のものを見ている理由は、すぐに実行できる2つのプロセス間の単純な競争です。その勝者は、マシンごとに、また時間の経過とともに変化するものに完全にかかっています。CPUが仮想であるという事実と同様に、システム負荷によって違いが生じます。

興味深いケースでは、ステップ2の詳細は次のとおりです。

1. Bourne Againシェルは継続します。
2. 組み込みkillコマンドの内部の一部として、次の利用可能なポイントで印刷される通知メッセージが必要であることをジョブテーブルのエントリにマークします。
3. killコマンドを終了し、プロンプトを出力する直前に、ジョブに関する通知メッセージを出力するかどうかを再度確認します。
4. yesプロセスはこれまでシェルはジョブが停止状態にあるに関しては、まだ自分自身を殺すために機会がなかったです。そのため、シェルはそのジョブの「Stopped」ジョブステータス行を出力し、その通知保留フラグをリセットします。
5. yesプロセスは、スケジュールと自分自身を殺します。
6. カーネルは、コマンドラインエディターの実行でビジー状態のシェルに、プロセスが強制終了したことを通知します。シェルはステータスの変化を記録し、ジョブに通知保留中のフラグを再度立てます。
7. を押すだけでenter、プロンプトの印刷を繰り返すことで、シェルは新しいジョブステータスを印刷できます。

重要な点は次のとおりです。

• プロセスは自殺します。 SIGKILL魔法ではありません。プロセスは、ページフォールト、（ネストされていない）割り込み、およびシステムコールの最後に発生する、カーネルモードからアプリケーションモードに戻るときに、保留中の信号をチェックします。唯一の特別な点は、カーネルはSIGKILL、アプリケーションモードに戻らずに、即時の無条件の自殺以外のことに対応するアクションを許可しないことです。重要なのは、プロセスがカーネル・ツー・アプリケーション・モード遷移を行うことの両方に必要と信号に対応するために実行するようにスケジュールすること。
• 仮想CPUは、ホストオペレーティングシステム上の単なるスレッドです。ホストが仮想CPUの実行をスケジュールしているという保証はありません。ホストオペレーティングシステムも魔法ではありません。
• （を使用しない限りset -o notify）ジョブの状態が変化しても通知メッセージは出力されません。これらは、次にシェルが実行サイクルのポイントに達したときに出力され、保留中の通知があるかどうかを確認します。
• 通知保留フラグはkill、SIGCHLDシグナルハンドラによって1回と2回設定されます。つまり、自分自身を強制終了するために再スケジュールされているプロセスの前にシェルが実行されている場合、2つのメッセージが表示yesされます。1つは「停止」メッセージ、もう1つは「強制終了」メッセージです。
• 明らかに、/bin/killプログラムはシェルの内部ジョブテーブルにアクセスできません。したがって、このような動作はで確認できません/bin/kill。通知保留フラグは、SIGCHLDハンドラーによって一度だけ設定されます。
• 同じ理由で、別のシェルからプロセスを実行した場合kill、この動作は発生しませんyes。

お使いのシステムでファンキーなことが起こっている可能性があります。私のものでは、レシピありとなしの両方でうまく機能します-9。

> yes
...
^Z
[1]+  Stopped                 yes
> jobs
[1]+  Stopped                 yes
> kill %1
[1]+  Killed                  yes
> jobs
> 

pidを取得して、jobs -pそれをkillしてみてくださいroot。

観察しているのは、このバージョンのbashのバグです。

kill -9 %1すぐにジョブを強制終了します。でそれを観察することができpsます。bashプロセスをトレースしてkillシステムコールがいつ呼び出されたかを確認し、サブプロセスをトレースして信号を受信して​​処理するタイミングを確認できます。さらに興味深いことに、プロセスに何が起こっているのかを確認することができます。

bash-4.3$ sleep 9999
^Z
[1]+  Stopped                 sleep 9999
bash-4.3$ kill -9 %1

[1]+  Stopped                 sleep 9999
bash-4.3$ jobs
[1]+  Stopped                 sleep 9999
bash-4.3$ jobs -l
[1]+  3083 Stopped                 sleep 9999
bash-4.3$ 

別のターミナルで：

% ps 3083
  PID TTY      STAT   TIME COMMAND
 3083 pts/4    Z      0:00 [sleep] <defunct>

サブプロセスはゾンビです。それは死んだ：残っているのはプロセステーブルのエントリだけです（ただし、メモリ、コード、開いているファイルなどはありません）。エントリは、その親が気づき、waitシステムコールまたはその兄弟の1つを呼び出すことによってその終了ステータスを取得するまで残されます。

インタラクティブシェルは、死んだ子をチェックし、プロンプトを出力する前にそれらを取得することになっています（特に設定されていない限り）。このバージョンのbashは、いくつかの状況で失敗します。

bash-4.3$ jobs -l
[1]+  3083 Stopped                 sleep 9999
bash-4.3$ true
bash-4.3$ /bin/true
[1]+  Killed                  sleep 9999

killコマンドの後にプロンプ​​トを出力するとすぐにbashが「Kill​​ed」を報告することを期待するかもしれませんが、競合状態があるため、これは保証されません。シグナルは非同期でkill配信されます。実際にシグナルが配信されるのを待たずに、カーネルがシグナルを配信するプロセスを特定すると、システムコールはすぐに戻ります。bashがサブプロセスのステータスを確認し、まだ死んでwait4いないことを確認し（子の死を報告しない）、プロセスがまだ停止していることを出力する時間を持つことが可能であり、実際に起こります。間違っているのは、次のプロンプトの前にシグナルが配信され（psプロセスが停止していることを報告）、それでもbashが呼び出されていないことですwait4（それでもジョブが「停止」と報告しているだけでなく、ゾンビがプロセステーブルにまだ存在していることがわかります）。実際、bashがゾンビを取得するのは、次にwait4他の外部コマンドを実行するときに、を呼び出す必要があるときだけです。

バグは断続的であり、bashがトレースされている間は再現できませんでした（おそらくbashが高速に反応する必要がある競合状態のためです）。シグナルがbashチェックの前に配信される場合、すべてが期待どおりに発生します。