Как Ctrl-C завершает дочерний процесс? - PullRequest
61 голосов
/ 24 мая 2011

Я пытаюсь понять, как CTRL + C завершает дочерний процесс, но не родительский процесс. Я вижу такое поведение в некоторых оболочках скриптов, таких как bash, где вы можете запустить какой-то длительный процесс, а затем завершить его, введя CTRL - C , и элемент управления возвращается в оболочку.

Не могли бы вы объяснить, как он работает и, в частности, почему не завершен родительский процесс (оболочка)?

Должна ли оболочка выполнять специальную обработку события CTRL + C и, если да, что именно она делает?

Ответы [ 5 ]

62 голосов
/ 24 мая 2011

Сигналы по умолчанию обрабатываются ядром. Старые системы Unix имели 15 сигналов; теперь у них больше. Вы можете проверить </usr/include/signal.h> (или убить -l). CTRL + C - это сигнал с именем SIGINT.

Действие по умолчанию для обработки каждого сигнала также определено в ядре и обычно завершает процесс, получивший сигнал.

Все сигналы (кроме SIGKILL) могут обрабатываться программой.

И вот что делает оболочка:

  • Когда оболочка работает в интерактивном режиме, она имеет специальную обработку сигналов для этого режима.
  • Когда вы запускаете программу, например find, оболочка:
    • fork с
    • и для ребенка установите обработку сигнала по умолчанию
    • заменить ребенка с помощью данной команды (например, с помощью find)
    • когда вы нажимаете CTRL + C , родительская оболочка обрабатывает этот сигнал, но дочерний элемент получает его - с действием по умолчанию - завершает работу. (ребенок тоже может осуществлять обработку сигналов)

Вы также можете trap сигналы в вашем сценарии оболочки ...

И вы также можете настроить обработку сигналов для своей интерактивной оболочки, попробуйте ввести это в верхней части ~/.profile. (Убедитесь, что вы уже вошли в систему и протестируйте его с помощью другого терминала - вы можете заблокировать себя)

trap 'echo "Dont do this"' 2

Теперь, каждый раз, когда вы нажимаете CTRL + C в вашей оболочке, он будет печатать сообщение. Не забудьте убрать строку!

Если интересно, вы можете проверить простую старую обработку /bin/sh сигнала в исходном коде здесь .

Выше было несколько дезинформаций в комментариях (теперь удалено), так что если кому-то интересно, очень хорошая ссылка - , как работает обработка сигналов .

21 голосов
/ 24 мая 2011

Сначала прочитайте статью Википедии о терминальном интерфейсе POSIX до конца.

Сигнал SIGINT генерируется дисциплиной линии терминала и транслируется всем процессам.в группе процессов переднего плана терминала.Ваша оболочка уже создала новую группу процессов для команды (или конвейера команд), которую вы выполнили, и сказала терминалу, что эта группа процессов является его (основной) группой процессов переднего плана.Каждый параллельный конвейер команд имеет свою собственную группу процессов, а конвейер команд foreground - это тот, в котором группа процессов запрограммирована оболочкой в ​​терминал как группа процессов переднего плана терминала.Переключение «заданий» между передним и задним планом (некоторые детали в стороне) - это вопрос оболочки, сообщающей терминалу, какая группа процессов сейчас является приоритетной.

Сам процесс оболочки находится в еще одной группе процессов во всех своихсобственной и поэтому не получает сигнал, когда одна из этих групп процессов находится на переднем плане.Это так просто.

7 голосов
/ 24 мая 2011

Терминал отправляет сигнал INT (прерывание) процессу, который в данный момент подключен к терминалу.Затем программа получает его и может выбрать его игнорирование или выход.

Ни один процесс не обязательно принудительно закрывается (хотя по умолчанию, если вы не обрабатываете sigint, я считаю, что поведение заключается в вызове abort(), но мне нужно это посмотреть).

Конечно, запущенный процесс изолирован от оболочки, которая его запустила.

Если вы хотели запустить родительскую оболочку, запустите вашу программу с помощью exec:

exec ./myprogram

Таким образом, родительская оболочка будет заменена дочерним процессом

2 голосов

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 upstream .

Компилировать с:

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 на терминале отправляет уничтожение всей группе процессов по умолчанию

Выйдите из программы, отправив разные сигналы обоим процессам, например, SIGQUIT с Ctrl + \.

Запуск с setpgid

Если вы запускаете с аргументом, например ::

./setpgid 1

тогда дочерний объект меняет свой pgid, и теперь каждый раз из родительского файла печатается только один знак:

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.

1 голос
/ 24 мая 2011

CTRL + C - сопоставление с командой kill. Когда вы нажимаете их, kill отправляет сигнал SIGINT, который прерывает процесс.

Убийство: http://en.wikipedia.org/wiki/Kill_(command)

SIGINT: http://en.wikipedia.org/wiki/SIGINT_(POSIX)

...