Как составить список всех доступных сигналов Linux

Обновлено: 21.11.2024

Сигналы LINUX

Особенностью программирования под LINUX является идея отправки и получения сигналов. Сигнал — это своего рода (обычно программное) прерывание, используемое для оповещения процесса об асинхронных событиях.

Что происходит, когда поступает сигнал?

<УЛ> игнорировать

закрыть

завершить работу и создать дамп ядра

остановить или приостановить программу

возобновить программу, приостановленную ранее

Каждый сигнал имеет текущее "расположение", указывающее, какое действие будет выполняться по умолчанию; дополнительная возможность состоит в том, чтобы иметь определяемую программистом функцию, которая будет служить обработчиком сигнала.

Примером использования сигналов является использование функции waitpid(). Он переводит вызывающий процесс в состояние ожидания (действие = STOP) до тех пор, пока указанный дочерний процесс не изменит свое состояние, о чем будет сообщено сигналом SIGCHILD (действие = возобновление). По умолчанию waitpid() ожидает завершения дочернего процесса, но есть способы изменить это, чтобы можно было обрабатывать другие изменения состояния.

Количество возможных сигналов ограничено. Первые 31 сигнал стандартизированы в LINUX; все имеют имена, начинающиеся с SIG. Некоторые из POSIX.

Обратите внимание на SIGUSR1 и SIGUSR2. Они доступны для индивидуального использования. Для каждого действия по умолчанию является Завершить, но программист может изменить это. Программист может использовать их, чтобы обеспечить абсолютно минимальный объем связи, т. е. «что-то произошло», между процессами.

Когда процесс использует функцию fork()), дочерний процесс наследует копию расположения сигналов своего родителя. Если затем дочерний процесс использует одну из функций exec(), статус всех сигналов сбрасывается либо на игнорирование, либо на значение по умолчанию, независимо от ситуации в родительском процессе.

Процесс может изменить расположение сигнала с помощью функции sigaction():

Это изменяет действие, выполняемое процессом, когда он получает определенный сигнал S (любой сигнал, кроме SIGKILL и SIGSTOP). Если Act не равен нулю, новое действие устанавливается из Act. Если OldAct не равен нулю, в нем сохраняется предыдущее действие. Здесь sigaction содержит адрес обработчика и некоторые другие данные, такие как маска сигналов, которые будут заблокированы во время выполнения обработчика. Написание обработчика требует некоторой осторожности, так как ваша программа прерывается, и вы не знаете, в какой момент.

Альтернативой является функция signal(), более простая в использовании, но менее стандартизированная, чем sigaction().

Если мы хотим иметь собственную функцию для обработки сигнала, она может выглядеть так:

Если у нас есть несколько потоков, расположение сигнала одинаково для всех потоков.

Это посылает сигнал S вызывающему потоку (отсюда getpid()). Если вызывается обработчик, raise() возвращается после возврата обработчика. Возвращаемое значение: 0 в случае успеха и -1 в случае неудачи.

Это отправляет сигнал S указанному процессу (если PID > 0) или всем членам указанной группы процессов (если PID = 0) или всем процессам в системе (если PID = -1). Возвращаемое значение равно 0, если был установлен хотя бы один сигнал, и -1 в случае ошибок.

Это отправляет сигнал S всем членам указанной группы процессов, чей идентификатор группы процессов равен PGroup. Возвращаемое значение равно 0, если был установлен хотя бы один сигнал, и -1 в случае ошибок.

Это отправляет сигнал S в указанный поток с идентификатором потока TID в том же процессе, что и вызывающий. (Внутренне это использует tqkill().) Возвращаемое значение равно 0 в случае успеха и -1 в случае ошибки.

Это отправляет сигнал S в указанный поток с потоком в указанной группе потоков с возвращаемым значением 0 в случае успеха и -1 в случае ошибок.

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

Также помните, что у нас есть функции wait() и waitpid(). Они будут ждать изменения состояния любого дочернего процесса или указанного дочернего процесса. Изменение состояния может состоять в том, что дочерний процесс был завершен, дочерний процесс был остановлен по сигналу или дочерний процесс был возобновлен по сигналу.

Что такое маска сигнала?

Сигнал может быть "заблокирован", поэтому он не будет доставлен, пока не будет "разблокирован". Пока сигнал ожидает между генерацией и доставкой, он находится в состоянии ожидания.

Каждый поток в процессе имеет собственную маску сигналов, в которой перечислены сигналы, блокируемые этим потоком в данный момент. Поток может изменить свою сигнальную маску с помощью pthread_sigmask(), а (однопоточный) процесс может сделать это с помощью sigprocmask().

Если процесс создает дочерний процесс с помощью fork(), дочерний процесс наследует копию маски сигнала своего родителя, и она сохраняется, даже если затем вызывается одна из функций exec().

Пример программы C для перехвата сигнала (с веб-страницы)

Большинство пользователей Linux используют комбинацию клавиш Ctr+C для завершения процессов в Linux.

Вы когда-нибудь задумывались о том, что за этим стоит? Итак, всякий раз, когда нажимается Ctrl+C, процессу отправляется сигнал SIGINT. По умолчанию этот сигнал завершает процесс. Но этот сигнал тоже можно обработать. Следующий код демонстрирует это:

В приведенном выше коде мы смоделировали длительный процесс, используя бесконечный цикл while.

В качестве обработчика сигнала используется функция sig_handler. Эта функция "регистрируется" в ядре, передавая ее в качестве второго аргумента сигнала системного вызова в функции main(). Первый аргумент функции signal — это сигнал, который должен обрабатываться обработчиком сигнала. В данном случае это SIGINT.

Кроме того, у использования функции sleep(1) есть причина. Эта функция использовалась в цикле while, так что цикл while выполняется через некоторое время (т. е. через одну секунду в данном случае). Это становится важным, потому что в противном случае бесконечный цикл while может потреблять большую часть ЦП, делая компьютер очень-очень медленным.

В любом случае, возвращаясь назад, когда процесс запускается и мы пытаемся завершить процесс с помощью Control-C, мы получаем:

В приведенном выше выводе мы видим, что мы пытались нажать комбинацию клавиш Control+C несколько раз, но каждый раз процесс не завершался. Это связано с тем, что сигнал обрабатывался в коде, и это подтверждалось печатью, которую мы получали в каждой строке.

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

На самом деле в приведенном выше примере есть проблема. Код для обработчика сигнала должен быть реентерабельным. Почему? Когда вызывается обработчик сигнала, процесс ожидает, пока выполняется обработчик. Что, если появится другой сигнал? Второй сигнал может быть обработан сразу, после чего возобновится обработчик первого сигнала. У нас может быть стек обработчиков.

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

Обратите внимание, что мы можем выйти из этой программы с помощью Control-Z или Control-\.

В этом примере обработчик сигнала всего лишь изменяет значение одной атомарной переменной.

В вашей системе есть справочная страница со списком всех доступных сигналов, но в зависимости от вашей операционной системы она может открываться по-разному. В большинстве систем Linux это будет man 7 signal. Если вы сомневаетесь, найдите точную справочную страницу и раздел, используя такие команды, как

man -k сигнал | список grep

По поводу сигнала | список grep

Имена сигналов можно найти с помощью команды kill -l .

При отсутствии ловушек интерактивная оболочка Bash игнорирует сигналы SIGTERM и SIGQUIT. SIGINT перехватывается и обрабатывается, и если управление заданиями активно, SIGTTIN, SIGTTOU и SIGTSTP также игнорируются. Команды, которые запускаются в результате подстановки команд, также игнорируют эти сигналы при генерации клавиатуры.

SIGHUP по умолчанию выходит из оболочки. Интерактивная оболочка отправит SIGHUP всем заданиям, запущенным или остановленным; см. документацию по встроенному disown, если вы хотите отключить это поведение по умолчанию для определенного процесса. Используйте опцию huponexit для уничтожения всех заданий при получении сигнала SIGHUP, используя встроенный магазин.

С помощью оболочки Bash можно отправлять следующие сигналы:

Таблица 12-1. Сигналы управления в Bash

< TD ALIGN="LEFT" VALIGN="MIDDLE" >Отложенный символ приостановки. Вызывает остановку запущенного процесса, когда он пытается прочитать ввод с терминала. Управление возвращается оболочке, пользователь может активировать, фонировать или завершить процесс. Отложенная приостановка доступна только в операционных системах, поддерживающих эту функцию.

Стандартная комбинация клавиш	Значение
Ctrl + C	Сигнал прерывания отправляет SIGINT заданию, работающему на переднем плане.
Ctrl + Y
Ctrl + Z	Сигнал приостановки отправляет SIGTSTP запущенной программе, тем самым останавливая ее и возвращая управление оболочке.

Настройки терминала

Проверьте настройки stty.Приостановка и возобновление вывода обычно отключены, если вы используете «современные» эмуляции терминала. Стандартный xterm по умолчанию поддерживает Ctrl + S и Ctrl + Q.

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

Используя команду kill из /usr/bin , ваша система может активировать дополнительные параметры, такие как возможность убивать процессы, не относящиеся к вашему собственному идентификатору пользователя, и указывать процессы по имени, например, с помощью pgrep и pkill .

Обе команды kill отправляют сигнал TERM, если он не указан.

Это список наиболее распространенных сигналов:

Таблица 12-2. Общие сигналы об убийстве

< TD ALIGN="LEFT" VALIGN="MIDDLE" >Сигнал отключения

SIGKILL и SIGSTOP нельзя перехватывать, блокировать или игнорировать.

При уничтожении процесса или серии процессов здравый смысл начинать с наименее опасного сигнала, SIGTERM . Таким образом, программы, заботящиеся об упорядоченном завершении работы, получают возможность следовать процедурам, которые они должны выполнять при получении сигнала SIGTERM, например, очищать и закрывать открытые файлы. Если вы отправляете процессу сигнал SIGKILL, вы лишаете его возможности выполнить аккуратную очистку и завершение работы, что может привести к нежелательным последствиям.

Но если чистое завершение не работает, сигналы INT или KILL могут быть единственным способом. Например, когда процесс не умирает с помощью Ctrl + C , лучше всего использовать kill -9 для этого идентификатора процесса:

мод: ~> ps -ef | grep sticked_process мод 5607 2214 0 20:05 pts/5 00:00:02 sticked_process мод: ~> kill -9 5607 мод: ~> ps -ef | grep застрял_процесс мод 5614 2214 0 20:15 pts/5 00:00:00 grep застрял_процесс [1]+ Убил застрял_процесс

Когда процесс запускает несколько экземпляров, killall может быть проще. Она принимает тот же параметр, что и команда kill, но применяется ко всем экземплярам данного процесса. Протестируйте эту команду, прежде чем использовать ее в производственной среде, поскольку она может работать не так, как ожидалось, на некоторых коммерческих Unix-системах.

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

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

Описание

Сигналы процесса были разработаны как часть UNIX в 1970-х годах. Они используются во всех современных Unix-подобных операционных системах, включая Linux, BSD и macOS X.

Когда процессу отправляется сигнал, операционная система прерывает нормальный поток выполнения процесса и доставляет уведомление. Если процесс ранее зарегистрировал способ обработки этого конкретного сигнала, выполняется эта подпрограмма, в противном случае система выполняет обработчик сигнала по умолчанию.

Сигналы можно отправлять с помощью команды kill, названной в честь сигнала по умолчанию (SIGKILL), который указывает ОС принудительно завершить процесс, прежде чем делать что-либо еще.

Имена сигналов обычно сокращаются без префикса SIG, например, "KILL", в том числе в аргументах команды kill.

Поиск системных сигналов

Сигналы определяются в системной библиотеке signal.h. Чтобы просмотреть сигналы, используемые вашей операционной системой, откройте терминал и запустите man signal или man 7 signal.

Сигналы в Linux

Имя сигнала	Значение сигнала	Эффект
SIGHUP	1	Отбой
SIGINT	2	Прерывание с клавиатуры
SIGKILL	9
SIGTERM	15	Сигнал окончания
SIGSTOP	17,19,23	Остановить процесс
SIGKILL и SIGSTOP

< tr >< td>SIGQUIT < td>5< td>SIGSEGV < /tr> < td>4.2 BSD < td>27 < td>28 < td>Неиспользуемый сигнал. Этот сигнал предоставляется по соображениям совместимости, например, при переносе программного обеспечения из операционной системы с другими или неподдерживаемыми сигналами в Linux. В Linux SIGSYS является синонимом SIGUNUSED.

Сигнал	Номер	Описание	Стандарт
SIGHUP	1	Сигнал HUP отправляется процессу, когда его управляющий терминал закрыт. Первоначально он был разработан для уведомления об отключении последовательной линии (HUP означает «повесить трубку»).В современных системах этот сигнал обычно указывает на то, что управляющий псевдо- или виртуальный терминал закрыт.	POSIX
SIGINT	2	Сигнал INT отправляется процессу его управляющим терминалом, когда пользователь хочет прервать процесс. Этот сигнал часто инициируется нажатием Ctrl + C , но в некоторых системах можно использовать символ «удалить» или клавишу «разрыв».	ANSI
3	Сигнал QUIT отправляется процессу его управляющим терминалом, когда пользователь запрашивает, чтобы процесс выполнил дамп ядра.	POSIX
SIGILL	4	Недопустимая инструкция. Сигнал ILL отправляется процессу, когда он пытается выполнить некорректную, неизвестную или привилегированную инструкцию.	ANSI
SIGTRAP	Ловушка трассировки. Сигнал TRAP отправляется процессу, когда возникает условие, отслеживаемое отладчиком, например, когда выполняется определенная функция или когда изменяется значение определенной переменной.	POSIX
SIGABRT, SIGIOT	6	Прервать процесс. ABRT обычно отправляется самим процессом, когда он вызывает системный вызов abort(), чтобы сигнализировать об аварийном завершении, но он может быть отправлен из любого процесса, как и любой другой сигнал. SIGIOT является синонимом SIGABRT. (IOT расшифровывается как прерывание ввода/вывода, сигнал, исходящий от PDP-11.)	4.2 BSD
SIGBUS	7	Сигнал BUS отправляется процессу, когда он вызывает ошибку шины, такую как неправильное выравнивание доступа к памяти или несуществующий физический адрес. В Linux этот сигнал соответствует SIGUNUSED, поскольку ошибки доступа к памяти такого рода невозможны.	4.2 BSD
SIGFPE	8	Исключение с плавающей запятой. Сигнал FPE отправляется процессу, когда он выполняет ошибочные арифметические операции, такие как деление на ноль.	ANSI
SIGKILL	9	Принудительно завершить процесс. В STOP это один из двух сигналов, которые не могут быть перехвачены, проигнорированы или обработаны самим процессом.	POSIX
SIGUSR1	10	Определяемый пользователем сигнал 1. Это один из двух сигналов, предназначенных для пользовательской обработки сигналов.	POSIX
11	Сигнал SEGV отправляется процессу, когда он делает недопустимую ссылку на виртуальную память или ошибку сегментации, т. е. когда он выполняет нарушение сегментации.
SIGUSR2	12	Определяемый пользователем сигнал 2. Это один из двух сигналов, предназначенных для пользовательской обработки сигналов пользователя.	POSIX
SIGPIPE	13	Сигнал PIPE отправляется процессу, когда он пытается записать в канал без процесса, подключенного к другому концу.	POSIX
SIGALRM	14	ALRM signal уведомляет процесс об истечении временного интервала, указанного в вызове системной функции alarm(). ред.	POSIX
SIGTERM	15	Сигнал TERM отправляется процессу для запроса его прекращение. В отличие от сигнала KILL, он может быть перехвачен и интерпретирован или проигнорирован процессом. Этот сигнал позволяет процессу выполнить красивое завершение, освобождая ресурсы и сохраняя состояние, если это необходимо. Следует отметить, что SIGINT почти идентичен SIGTERM.	ANSI
SIGSTKFLT	16	Ошибка стека. Сопоставляется с SIGUNUSED в Linux.
SIGCHLD	17	Сигнал CHLD отправляется процессу, когда завершается дочерний процесс, прерывается или возобновляется после прерывания. Одним из распространенных способов использования сигнала является указание операционной системе очистить ресурсы, используемые дочерним процессом после его завершения, без явного вызова системного вызова ожидания.	POSIX
SIGCONT	18	Продолжить выполнение после остановки, например, командой STOP	POSIX
SIGSTOP	19	Сигнал STOP указывает операционной системе остановить процесс для последующего возобновления. Это один из двух сигналов, наряду с KILL, который не может быть перехвачен, проигнорирован или обработан самим процессом.	POSIX
SIGTSTP	20	Сигнал TSTP отправляется процессу его управляющим терминалом, чтобы запросить его временную остановку. Обычно он инициируется пользователем, нажимающим Ctrl + Z . В отличие от SIGSTOP, этот процесс может зарегистрировать обработчик сигнала или игнорировать сигнал.	POSIX
SIGTTIN	21	Сигнал TTIN отправляется процессу, когда он пытается прочитать с tty в фоновом режиме. Этот сигнал может быть получен только процессами, находящимися под управлением задания. Демоны не имеют управляющих терминалов и никогда не должны получать этот сигнал.	POSIX
SIGTTOU	22	Сигнал TTOU отправляется процессу, когда он пытается записать с tty в фоновом режиме. Дополнение к TTIN.	POSIX
SIGURG	23	Сигнал URG отправляется в обрабатывать, когда сокет имеет срочные или внеполосные данные, доступные для чтения.	4.2 BSD
SIGXCPU	24< /td>	Сигнал XCPU отправляется процессу, когда он израсходовал ресурсы ЦП на время, превышающее определенное заданное пользователем значение. Поступление сигнала XCPU дает процессу-получателю возможность быстро сохранить любые промежуточные результаты и корректно завершить работу до того, как операционная система завершит его с помощью сигнала SIGKILL.	4.2 BSD
SIGXFSZ	25	Сигнал XFSZ отправляется процессу, когда он увеличивает размер файла, превышающий максимально допустимый размер.
SIGVTALRM	26	Виртуальный будильник. Может быть отправлен системным вызовом alarm(). По умолчанию этот сигнал убивает процесс, но он предназначен для использования с обработкой сигналов, зависящих от процесса.	4.2 BSD
SIGPROF	Профилирующий будильник. Указывает на истечение срока действия таймера, который измеряет время ЦП, используемое текущим процессом («время пользователя»), и время ЦП, затраченное системой от имени процесса («системное» время). Это время можно использовать для реализации средств профилирования кода. По умолчанию этот сигнал завершает процесс, но он предназначен для обработки сигналов конкретного процесса.	4.2 BSD
SIGWINCH	Смена окна. Сигнал WINCH отправляется процессу, когда его управляющий терминал изменяет размер, например, если вы изменяете его размер в оконном менеджере.	4.3 BSD, Sun
SIGIO, SIGPOLL	29	Ввод/вывод теперь возможен. SIGPOLL является синонимом SIGIO, и в Linux его поведение идентично SIGURG.	4.2 BSD
SIGPWR, SIGLOST	30	Отказ питания. Сигнал PWR отправляется процессу, когда система обнаруживает сбой питания. SIGLOST является синонимом SIGPWR.	System V
SIGUNUSED, SIGSYS	31	System V r4

Сигналы, не поддерживаемые Linux

Следующие сигналы могут использоваться другими системами, такими как BSD, но интерпретируются как SIGUNUSED в Linux.

SIGEMT	Сигнал ЕМТ отправляется процессу при возникновении ловушки эмулятора. Не используется в Linux.
SIGINFO	Сигнал INFO отправляется процессу, когда от управляющего терминала поступает запрос состояния. Не используется в Linux
SIGLOST	Сигнал LOST отправляется процессу при потере блокировки файла. Не используется в Linux.
SIGSYS	Сигнал SYS отправляется процессу, когда он передает системному вызову неверный аргумент. Не используется в Linux.

Отправка сигналов с клавиатуры

Сигналы могут быть отправлены с клавиатуры. Несколько стандартных значений по умолчанию перечислены ниже. Комбинации клавиш по умолчанию для отправки сигналов прерывания можно определить с помощью команды stty.

Ctrl-C	Отправить SIGINT (прерывание). По умолчанию это приводит к завершению процесса.
Ctrl-Z	Отправить SIGTSTP (приостановить). По умолчанию это приводит к тому, что процесс приостанавливает все операции.
Ctrl-\	Отправить SIGQUIT (Выход). По умолчанию это приводит к немедленному завершению процесса и сбросу ядра.
Ctrl-T	Отправить SIGINFO (информация). По умолчанию это заставляет операционную систему отображать информацию о команде. Поддерживается не во всех системах.

Сигналы в реальном времени

Сигналы реального времени – это набор сигналов без заранее определенной цели, которые программисты могут использовать по своему усмотрению в своем программном обеспечении. Два имени сигнала, SIGRTMIN и SIGRTMAX, определяют минимальное и максимальное количество сигналов реального времени. Например, программист может использовать номер сигнала SIGRTMIN+3 для ссылки на четвертый номер сигнала реального времени.

Примеры: отправка сигналов

Команда kill отправляет сигналы процессам. Ваша оболочка может иметь встроенную версию kill, которая заменяет версию, установленную в /bin/kill. Две версии имеют немного разные параметры, но основные функции одинаковы. Следующие примеры могут выполняться с использованием любой версии kill.

Процесс, о котором необходимо сигнализировать, определяется PID (идентификатором процесса). Если вы не уверены в идентификаторе процесса, его можно найти с помощью команды ps, например ps -aux.

Отправить сигнал KILL процессу с PID 1234.

Убить три процесса: PID 123, 456 и 789.

Отправить сигнал номер 15 (TERM) процессам 1234 и 5678.

То же, что и предыдущая команда.

Список всех доступных сигналов. Пример вывода:

Специальный идентификатор процесса -1 относится ко всем процессам, кроме kill и системного корневого процесса. Эта команда пытается убить (-9) все возможные процессы (-1) в системе. Для получения дополнительной информации см. документацию kill, ссылка на которую приведена ниже.

Связанные команды

kill — завершить процесс.
stty — изменить настройки линии терминала.

Как проверить, поймает ли работающий процесс сигнал, проигнорирует его или заблокирует? В идеале я хотел бы видеть список сигналов или, по крайней мере, не отправлять сигнал для проверки.

9 ответов 9

В Linux вы можете найти PID вашего процесса, а затем просмотреть /proc/$PID/status . Он содержит строки, описывающие, какие сигналы блокируются (SigBlk), игнорируются (SigIgn) или перехватываются (SigCgt).

Число справа — это битовая маска. Если вы преобразуете его из шестнадцатеричного в двоичный, каждый 1 бит представляет перехваченный сигнал, считая справа налево, начиная с 1. Таким образом, интерпретируя строку SigCgt, мы можем видеть, что мой процесс инициализации перехватывает следующие сигналы:

(Я нашел сопоставление числа с именем, запустив команду kill -l из bash.)

EDIT: И, по многочисленным просьбам, скрипт в POSIX sh.

Если сигнал указан в SigBlk, отображается ли он также в SigCgt? Потому что, блокируя его, это просто означает, что сигнал будет повторно отправлен немного позже, верно, и его нужно поймать?

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

Какая польза от POSIX-версии скрипта, читающего из /proc ? Это будет работать только на Linux. И локальный не POSIX. Ну, вроде так, но его эффект "не указан".

@Kusalananda: Linux не подразумевает Bash — например, небольшие встраиваемые платформы часто используют Busybox — но соответствие POSIX является почти гарантией для любого современного /bin/sh . Вы правы насчет local ; Я уберу это.

В Solaris запустите psig для идентификатора процесса, чтобы получить список сигналов и способы их обработки.

что показывает, что SIGHUP, SIGILL и т. д. будут перехвачены одной и той же функцией обработчика сигналов termsig_sighandler , которая будет запущена без использования каких-либо флагов, которые можно установить с помощью sigaction , и все сигналы будут временно замаскированы. пока работает обработчик сигнала (в данном случае все те, которые используют один и тот же обработчик сигнала, поэтому он не вводится повторно, пока он уже запущен). Вы также можете видеть, что SIGQUIT и SIGTERM будут игнорироваться, SIGKILL и SIGPWR используют системные действия сигнала по умолчанию, а SIGCLD указывает флаг RESTART, поэтому, если его обработчик сигнала прерывает системный вызов, системный вызов будет перезапущен.

Читайте также: