親プロセスに送信されたときにSIGINTが子プロセスに伝播されないのはなぜですか?


62

シェルプロセス(例sh)とその子プロセス(例cat)が与えられた場合、シェルのプロセスIDを使用してCtrl+ の動作をどのようにシミュレートできCますか?


これは私が試したものです:

実行shしてからcat

[user@host ~]$ sh
sh-4.3$ cat
test
test

送信SIGINTcat別の端末から:

[user@host ~]$ kill -SIGINT $PID_OF_CAT

cat 信号を受信して​​終了しました(予想どおり)。

親プロセスにシグナルを送信しても機能しないようです。親プロセスに送信されたcatときに信号が伝播されないのはなぜshですか?

これは動作しません:

[user@host ~]$ kill -SIGINT $PID_OF_SH

1
シェルには、キーボードまたは端末から送信されないSIGINTシグナルを無視する方法があります。
konsolebox 14

回答:


86

どのようにCTRL+ C作品

最初に行うことは、CTRL+のC仕組みを理解することです。

CTRL+ を押すCと、端末エミュレータはETX文字(テキストの終わり/ 0x03)を送信します。
TTYは、この文字を受信すると、端末のフォアグラウンドプロセスグループにSIGINTを送信するように構成されています。この構成では、実行して見ることができるsttyと見てintr = ^C;POSIX仕様では、 INTRを受信したとき、それはその端末のフォアグラウンドプロセスグループにSIGINTを送るべきであると述べています。

フォアグラウンドプロセスグループとは何ですか?

それで、質問は、フォアグラウンドプロセスグループがどのように決定されるのかということです。フォアグラウンドプロセスグループは、キーボードで生成されたシグナル(SIGTSTOP、SIGINTなど)を受信するプロセスのグループです。

プロセスグループIDを決定する最も簡単な方法は、以下を使用することpsです。

ps ax -O tpgid

2番目の列はプロセスグループIDです。

プロセスグループにシグナルを送信するにはどうすればよいですか?

プロセスグループIDがわかったので、グループ全体に信号を送信するPOSIXの動作をシミュレートする必要があります。

これは、グループIDの前にをkill置くことで実行でき-ます。
たとえば、プロセスグループIDが1234の場合、次を使用します。

kill -INT -1234

 


端末番号を使用してCTRL+ Cをシミュレートします。

したがって、上記は手動プロセスとしてCTRL+ をシミュレートする方法をカバーしていCます。しかし、TTY番号がわかっていて、その端末のCTRL+ をシミュレートしたい場合はどうでしょCうか?

これは非常に簡単になります。

$ttyターゲティングするターミナルを想定します(tty | sed 's#^/dev/##'ターミナルで実行することで取得できます)。

kill -INT -$(ps h -t $tty -o tpgid | uniq)

これは、フォアグラウンドプロセスグループが何であれ、SIGINTを送信します$tty


6
端末から直接送信される信号は許可チェックをバイパスするため、killコマンドが失敗する可能性があるのに対して、端末属性でオフにしない限り、Ctrl + Cは常に信号の配信に成功することに注意してください。
ブライアンビ

4
+ 1、for sends a SIGINT to the foreground process group of the terminal.
andy

子のプロセスグループは後に親と同じであることを言及する価値がありますfork。最小の実行可能なCの例:unix.stackexchange.com/a/465112/32558
Ciro Santilli新疆改造中心法轮功六四事件

15

vinc17が言うように、これが起こる理由はありません。シグナル生成キーシーケンス(例:Ctrl+ C)を入力すると、ターミナルに接続されている(関連付けられている)すべてのプロセスにシグナルが送信されます。によって生成される信号には、そのようなメカニズムはありませんkill

ただし、次のようなコマンド

kill -SIGINT -12345

プロセスグループ 12345のすべてのプロセスに信号を送信します。kill(1) およびkill(2)を参照してください。シェルの子は通常、シェルのプロセスグループに属します(少なくとも、非同期でない場合)。したがって、シェルのPIDの負にシグナルを送信すると、必要な処理を実行できます。


おっと

vinc17が指摘しているように、これは対話型シェルでは機能しません。動作する可能性のある代替手段は次のとおりです。

kill -SIGINT-$(echo $(ps -p PID_of_shell o tpgid =))

ps -pPID_of_shellシェルのプロセス情報を取得します。  o tpgid=指示psなしヘッダと、端末のみの処理グループIDを出力します。これが10000未満の場合ps、先頭にスペースを付けて表示します。これ$(echo …)は、先頭(および末尾)のスペースを取り除く簡単なトリックです。

Debianマシンでの大まかなテストでこれを機能させました。


1
これは、プロセスがインタラクティブシェル(OPが使用しているもの)で開始された場合は機能しません。ただし、この動作に関するリファレンスはありません。
vinc17 14

12

質問には独自の回答が含まれています。をプロセスに送信するSIGINTと、を押したときに何が起こるかを完全にシミュレートできます。catkill^C

より正確には、割り込み文字(^Cデフォルト)SIGINTは、端末のフォアグラウンドプロセスグループ内のすべてのプロセスに送信します。cat複数のプロセスを含むより複雑なコマンドを実行する代わりに、プロセスグループを強制終了して、と同じ効果を達成する必要があり^Cます。

&バックグラウンド演算子を使用せずに外部コマンドを実行すると、シェルはコマンドの新しいプロセスグループを作成し、このプロセスグループがフォアグラウンドになったことを端末に通知します。シェルはまだ独自のプロセスグループにあり、フォアグラウンドにはありません。次に、シェルはコマンドが終了するのを待ちます。

そこが、よくある誤解によって犠牲になったように見える場所です。シェルは、子プロセスと端末間の相互作用を促進するために何かをしているという考えです。それは本当ではありません。セットアップ作業(プロセスの作成、ターミナルモードの設定、パイプの作成と他のファイル記述子のリダイレクト、ターゲットプログラムの実行)が完了すると、シェルは待機します。あなたがに入力すると、catそれは通常の入力などのシグナル発生の特殊文字のかどうか、シェルを介して行くのではありません^Ccatプロセスは、独自のファイル記述子を介して端末に直接アクセスし、端末が直接信号を送信する機能があるcatことがフォアグラウンドプロセスグループだからプロセスを。

catプロセスが終了すると、シェルはcatプロセスの親であるため通知されます。次に、シェルがアクティブになり、再び前面に表示されます。

理解を深めるための演習を次に示します。

新しいターミナルのシェルプロンプトで、次のコマンドを実行します。

exec cat

このexecキーワードにより、cat子プロセスを作成せずにシェルが実行されます。シェルはに置き換えられcatます。以前シェルに属していたPIDは、現在のPIDですcatps別の端末でこれを確認してください。いくつかのランダムな行を入力し、それがcat繰り返し表示されることを確認します。親としてシェルプロセスがないにもかかわらず、まだ正常に動作していることがわかります。今すぐ押すとどうなります^Cか?

回答:

SIGINTはcatプロセスに配信され、catプロセスは終了します。端末上の唯一のプロセスであるため、シェルプロンプトで「終了」と言ったように、セッションは終了します。実際、猫しばらくの間あなたの殻でした。


シェルは邪魔になりません。+1
ピョートルドブロゴスト

exec cat押した後に猫に^C着地^Cしないのはなぜかわかりません。catシェルを置き換えたものを終了するのはなぜですか?シェルは置き換えられているため、シェルはを受信し^CたときにSIGINTをその子に送信するロジックを実装するものです。
スティーブンルー

ポイントは、シェル SIGINTをその子に送信しないことです。SIGINTはターミナルドライバーから取得され、すべてのフォアグラウンドプロセスに送信されます。

3

SIGINT子に伝播する理由はありません。さらに、system()POSIX仕様では、「system()関数はSIGINTおよびSIGQUITシグナルを無視し、SIGCHLDシグナルをブロックし、コマンドの終了を待機します」と述べています。

SIGINTたとえば、実際のCtrl-Cに従って、シェルがreceiveを伝播した場合、これは子プロセスがSIGINTシグナルを2回受信することを意味し、望ましくない動作が発生する可能性があります。


シェルはこれを実装する必要はありませんsystem()。しかし、あなたが正しいのは、それがシグナルをキャッチする(明らかにキャッチする)場合、それを下方に伝播する理由はありません。
goldilocks 14

@goldilocksおそらくより良い理由を与えて、答えを完成させました。シェルは、子がすでにシグナルを受信したかどうかを知ることができないため、問題があることに注意してください。
vinc17 14

1

setpgid POSIX Cプロセスグループの最小例

基礎となるAPIの最小限の実行可能な例を使用すると、理解しやすくなる場合があります。

これは、子がでプロセスグループを変更しなかった場合に、子に信号が送信される方法を示していますsetpgid

main.c

#define _XOPEN_SOURCE 700
#include <assert.h>
#include <signal.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

volatile sig_atomic_t is_child = 0;

void signal_handler(int sig) {
    char parent_str[] = "sigint parent\n";
    char child_str[] = "sigint child\n";
    signal(sig, signal_handler);
    if (sig == SIGINT) {
        if (is_child) {
            write(STDOUT_FILENO, child_str, sizeof(child_str) - 1);
        } else {
            write(STDOUT_FILENO, parent_str, sizeof(parent_str) - 1);
        }
    }
}

int main(int argc, char **argv) {
    pid_t pid, pgid;

    (void)argv;
    signal(SIGINT, signal_handler);
    signal(SIGUSR1, signal_handler);
    pid = fork();
    assert(pid != -1);
    if (pid == 0) {
        is_child = 1;
        if (argc > 1) {
            /* Change the pgid.
             * The new one is guaranteed to be different than the previous, which was equal to the parent's,
             * because `man setpgid` says:
             * > the child has its own unique process ID, and this PID does not match
             * > the ID of any existing process group (setpgid(2)) or session.
             */
            setpgid(0, 0);
        }
        printf("child pid, pgid = %ju, %ju\n", (uintmax_t)getpid(), (uintmax_t)getpgid(0));
        assert(kill(getppid(), SIGUSR1) == 0);
        while (1);
        exit(EXIT_SUCCESS);
    }
    /* Wait until the child sends a SIGUSR1. */
    pause();
    pgid = getpgid(0);
    printf("parent pid, pgid = %ju, %ju\n", (uintmax_t)getpid(), (uintmax_t)pgid);
    /* man kill explains that negative first argument means to send a signal to a process group. */
    kill(-pgid, SIGINT);
    while (1);
}

GitHubアップストリーム

コンパイル:

gcc -ggdb3 -O0 -std=c99 -Wall -Wextra -Wpedantic -o setpgid setpgid.c

なしで実行 setpgid

CLI引数setpgidがない場合、実行されません。

./setpgid

可能な結果:

child pid, pgid = 28250, 28249
parent pid, pgid = 28249, 28249
sigint parent
sigint child

プログラムがハングします。

ご覧のとおり、両方のプロセスのpgidは同じで、継承されforkます。

その後、あなたがヒットするたびに:

Ctrl + C

再び出力します:

sigint parent
sigint child

これは次の方法を示しています。

  • プロセスグループ全体にシグナルを送信するには kill(-pgid, SIGINT)
  • 端末のCtrl + Cは、デフォルトでプロセスグループ全体にkillを送信します

両方のプロセスに異なるシグナルを送信してプログラムを終了します(例:SIGQUIT with)Ctrl + \

で実行 setpgid

引数を指定して実行する場合、たとえば:

./setpgid 1

子はそのpgidを変更し、親からのみ毎回1つのsigintのみが印刷されるようになりました:

child pid, pgid = 16470, 16470
parent pid, pgid = 16469, 16469
sigint parent

そして今、あなたがヒットするたびに:

Ctrl + C

親だけが信号も受信します:

sigint parent

以前と同様に、SIGQUITを使用して親を殺すことができます。

Ctrl + \

ただし、子は異なるPGIDを持ち、そのシグナルを受信しません!これは以下から見ることができます:

ps aux | grep setpgid

あなたはそれを明示的に殺す必要があります:

kill -9 16470

これにより、シグナルグループが存在する理由が明確になります。それ以外の場合は、常に手動でクリーニングするために残っているプロセスの束を取得します。

Ubuntu 18.04でテスト済み。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.