Как SIGINT относится к другим сигналам завершения?

В системах POSIX сигналы завершения обычно имеют следующий порядок (согласно многим страницам MAN и спецификации POSIX):

  1. SIGTERM - вежливо попросить завершить процесс. Он должен корректно завершаться, очищая все ресурсы (файлы, сокеты, дочерние процессы и т. Д.), Удаляя временные файлы и т. Д.

  2. SIGQUIT - более сильный запрос. Это должно прекратить неблагодарное, все еще очищая ресурсы, которые абсолютно нуждаются в очистке, но, возможно, не удаляют временные файлы, возможно записывают отладочную информацию где-нибудь; в некоторых системах также записывается дамп ядра (независимо от того, перехватывается ли сигнал приложением или нет).

  3. SIGKILL - самый сильный запрос. Процесс даже не просят что-либо сделать, но система очистит процесс, нравится он или нет. Скорее всего дамп ядра записан.

Как SIGINT вписывается в эту картину? Процесс CLI обычно завершается SIGINT, когда пользователь нажимает CRTL + C, однако фоновый процесс также может быть прекращен SIGINT с использованием утилиты KILL. Что я не могу увидеть в спецификациях или файлах заголовков, так это в том, что SIGINT более или менее силен, чем SIGTERM, или есть какая-либо разница между SIGINT и SIGTERM вообще.

UPDATE:

Лучшее описание сигналов завершения, которое я нашел до сих пор, находится в документации GNU LibC . Это очень хорошо объясняет, что есть намеренная разница между SIGTERM и SIGQUIT.

Это говорит о SIGTERM:

  

Это нормальный способ вежливо попросить программу завершиться.

И это говорит о SIGQUIT:

  

[...] и создает дамп ядра при завершении процесса, как сигнал об ошибке программы.   Вы можете думать об этом как об ошибке программы, «обнаруженной» пользователем. [...]   Некоторые виды очистки лучше всего не использовать при работе с SIGQUIT. Например, если программа   создает временные файлы, он должен обрабатывать другие запросы завершения, удаляя временные   файлы. Но для SIGQUIT лучше не удалять их, чтобы пользователь мог просмотреть их в   в сочетании с дампом ядра.

И SIGHUP также объясняется достаточно хорошо. SIGHUP на самом деле не является сигналом завершения, это просто означает, что «соединение» с пользователем потеряно, поэтому приложение не может ожидать, что пользователь прочитает какой-либо дальнейший вывод (например, вывод stdout /stderr), и нет никаких данных, ожидаемых от пользователь больше Для большинства приложений это означает, что они лучше выйти. Теоретически приложение может также решить, что при получении сигнала SIGHUP оно переходит в режим демона и теперь работает как фоновый процесс, записывая выходные данные в сконфигурированный файл журнала. Для большинства демонов, уже работающих в фоновом режиме, SIGHUP обычно означает, что они должны пересмотреть свои файлы конфигурации, поэтому вы отправляете их в фоновые процессы после редактирования файлов конфигурации.

Однако на этой странице нет никакого полезного объяснения SIGINT, кроме того, что оно отправлено CRTL + C. Есть ли какая-то причина, по которой можно было бы обращаться с SIGINT иначе, чем с SIGTERM? Если да, то какова причина этого и как будет отличаться обработка?

84 голоса | спросил Mecki 28 +04002010-10-28T14:59:31+04:00312010bEurope/MoscowThu, 28 Oct 2010 14:59:31 +0400 2010, 14:59:31

6 ответов


0

SIGTERM и SIGKILL предназначены для общих запросов «прекратить этот процесс». SIGTERM (по умолчанию) и SIGKILL (всегда) вызовут завершение процесса. SIGTERM может быть перехвачен процессом (например, чтобы он мог выполнить свою собственную очистку, если он хочет), или даже полностью игнорироваться; но SIGKILL не может быть пойман или проигнорирован.

SIGINT и SIGQUIT предназначены специально для запросов от терминала: для генерирования этих сигналов могут быть назначены определенные входные символы (в зависимости от настроек управления терминалом). Действие по умолчанию для SIGINT - это тот же вид завершения процесса, что и действие по умолчанию для SIGTERM и неизменяемое действие для SIGKILL; действием по умолчанию для SIGQUIT также является завершение процесса, но могут возникнуть дополнительные действия, определенные реализацией, такие как создание дампа ядра. Либо может быть перехвачен или проигнорирован процессом, если требуется.

SIGHUP, как вы говорите, предназначен для указания того, что терминальное соединение потеряно, а не как сигнал завершения как таковой. Но, опять же, действие по умолчанию для SIGHUP (если процесс не перехватывает или игнорирует его) - завершать процесс так же, как SIGTERM и т. Д.

В POSIX есть таблица для signal.h , в котором перечислены различные сигналы и их действия по умолчанию и цели, а Общий интерфейс терминала содержит гораздо больше подробностей о сигналах, связанных с терминалом. .

ответил Matthew Slattery 29 +04002010-10-29T03:35:03+04:00312010bEurope/MoscowFri, 29 Oct 2010 03:35:03 +0400 2010, 03:35:03
0

Как отметил DarkDust, многие сигналы имеют одинаковые результаты, но процессы могут назначать им различные действия, различая, как генерируется каждый сигнал. Глядя на исходный код ядра FreeBSD (kern_sig.c), я вижу, что два сигнала обрабатываются одинаково, они завершают процесс и доставляются в любой поток.

SA_KILL|SA_PROC,             /* SIGINT */
SA_KILL|SA_PROC,             /* SIGTERM */
ответил Diomidis Spinellis 28 +04002010-10-28T19:49:55+04:00312010bEurope/MoscowThu, 28 Oct 2010 19:49:55 +0400 2010, 19:49:55
0

После быстрого поиска в Google по запросу sigint vs sigterm , похоже, единственное различие между ними заключается в том, был ли он вызван сочетанием клавиш или явным вызовом kill

В результате вы можете, например, перехватить sigint и сделать с ним что-то особенное, зная, что он, вероятно, был отправлен с помощью сочетания клавиш. Возможно, обновите экран или что-то, вместо того, чтобы умереть (не рекомендуется, поскольку люди ожидают, что ^C, чтобы убить программу, просто пример).

Я также узнал, что ^\ должен отправить sigquit, который я могу начать использовать самостоятельно. Выглядит очень полезно.

ответил Jonathan 29 +04002010-10-29T17:39:08+04:00312010bEurope/MoscowFri, 29 Oct 2010 17:39:08 +0400 2010, 17:39:08
0

Некоторые из них являются ANSI C, а другие нет

Значительная разница в том, что:

  • SIGINT и SIGTERM - это ANSI C, поэтому они более переносимы
  • SIGQUIT и SIGKILL не являются

Они описаны в разделе "7.14 Обработка сигналов" в C99 черновик N1256 :

  • SIGINT получение интерактивного сигнала внимания
  • SIGTERM - запрос на прекращение, отправленный в программу

, что делает SIGINT хорошим кандидатом на интерактивные Ctrl + C.

ответил Ciro Santilli 新疆改造中心 六四事件 法轮功 15 PMpWed, 15 Apr 2015 22:57:20 +030057Wednesday 2015, 22:57:20
0

Используя kill (как системный вызов, так и утилита) вы можете отправить практически любой сигнал любому процессу, если у вас есть разрешение. Процесс не может различить, как сигнал ожил и кто его отправил.

Тем не менее, SIGINT на самом деле предназначен для обозначения прерывания Ctrl-C, в то время как SIGTERM является общим сигналом терминала. Нет понятия, что сигнал является «более сильным», за исключением того, что существуют сигналы, которые нельзя заблокировать или обработать (SIGKILL и SIGSTOP, согласно странице руководства).

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

ответил DarkDust 28 +04002010-10-28T15:23:19+04:00312010bEurope/MoscowThu, 28 Oct 2010 15:23:19 +0400 2010, 15:23:19
0

За исключением нескольких сигналов, обработчики сигналов могут перехватывать различные сигналы, или поведение по умолчанию при получении сигнала может быть изменено. Для получения дополнительной информации см. Справочную страницу signal(7).

ответил Ignacio Vazquez-Abrams 28 +04002010-10-28T15:20:45+04:00312010bEurope/MoscowThu, 28 Oct 2010 15:20:45 +0400 2010, 15:20:45

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132