signal(7) | Miscellaneous Information Manual | signal(7) |
signal - обзор сигналов
В Linux поддерживаются надёжные (reliable) сигналы POSIX (далее, «стандартные сигналы») и сигналы реального времени POSIX.
Каждый сигнал имеет текущий обработчик, который определяет, что будет делать процесс при поступлении сигнала.
В таблице далее есть столбец «Действие», в котором указан обработчик по умолчанию для каждого сигнала:
Процесс может изменить обработчик сигнала с помощью sigaction(2) или signal(2) (последний менее переносим, если используется для установки обработчика сигнала; дополнительную информацию смотрите в signal(2)). Используя данные системные вызовы процесс может выбрать одно из следующих действий при получении сигнала: выполнить действие по умолчанию, игнорировать сигнал, поймать сигнал обработчиком сигнала — функцией, задаваемой программистом, которая автоматически вызывается при получении сигнала.
По умолчанию обработчик сигнала использует обычный стек процесса. Возможно сделать так, чтобы обработчик сигнала использовал альтернативный стек; как это делается и когда это может быть полезно смотрите в sigaltstack(2).
Реакция на сигналы является атрибутом процесса: в многонитевом приложении реакция на определённый сигнал одинакова для всех нитей.
Потомок, созданный с помощью fork(2), наследует реакцию на сигналы от своего родителя. При execve(2) реакция на сигналы устанавливается в значение по умолчанию; реакция на игнорируемые сигналы не изменяется.
Для отправки сигнала можно использовать следующие системные вызовы и библиотечные функции:
Следующие системные вызовы приостанавливают выполнение вызывающей нити до тех пор, пока не будет пойман сигнал (или необработанный сигнал не завершит процесс):
В отличие от асинхронного получения сигнала через обработчик, возможно синхронно получить сигнал, то есть блокировать выполнение до поступления сигнала в некоторой точке, в которой ядро вернёт информацию о сигнале вызывающему. Для этого существует два пути:
Сигнал может быть заблокирован. Это означает, что он не будет доставлен до тех пор, пока не будет разблокирован. В промежуток времени от генерации сигнала и до его доставки о сигнале говорят как об ожидающем.
В каждой нити процесса имеется независимая сигнальная маска, определяющая набор сигналов, которые нить, в данный момент, блокирует. Нить может управлять сигнальной маской с помощью pthread_sigmask(3). В обычном однонитевом приложении для работы с сигнальной маской можно использовать вызов sigprocmask(2).
Потомок, создаваемый с помощью fork(2), наследует копию родительской маски сигналов; маска сигналов сохраняется при вызове execve(2).
A signal may be process-directed or thread-directed. A process-directed signal is one that is targeted at (and thus pending for) the process as a whole. A signal may be process-directed because it was generated by the kernel for reasons other than a hardware exception, or because it was sent using kill(2) or sigqueue(3). A thread-directed signal is one that is targeted at a specific thread. A signal may be thread-directed because it was generated as a consequence of executing a specific machine-language instruction that triggered a hardware exception (e.g., SIGSEGV for an invalid memory access, or SIGFPE for a math error), or because it was targeted at a specific thread using interfaces such as tgkill(2) or pthread_kill(3).
Направленный процессу сигнал может быть доставлен в любую из нитей, у которой сигнал не заблокирован. Если имеется несколько таких нитей, то ядро выбирает произвольную нить, которой и доставит сигнал.
Нить может получить набор сигналов, которые находятся в состоянии ожидания с помощью вызова sigpending(2). Этот набор будет состоять из объединения набора ожидающих сигналов, направленных процессу, и набора ожидающих сигналов для вызвавшей нити.
Потомок, созданный с помощью fork(2), первоначально имеет пустой набор ожидающих сигналов; набор ожидающих сигналов сохраняется при вызове execve(2).
Whenever there is a transition from kernel-mode to user-mode execution (e.g., on return from a system call or scheduling of a thread onto the CPU), the kernel checks whether there is a pending unblocked signal for which the process has established a signal handler. If there is such a pending signal, the following steps occur:
Note that if the signal handler does not return (e.g., control is transferred out of the handler using siglongjmp(3), or the handler executes a new program with execve(2)), then the final step is not performed. In particular, in such scenarios it is the programmer's responsibility to restore the state of the signal mask (using sigprocmask(2)), if it is desired to unblock the signals that were blocked on entry to the signal handler. (Note that siglongjmp(3) may or may not restore the signal mask, depending on the savesigs value that was specified in the corresponding call to sigsetjmp(3).)
From the kernel's point of view, execution of the signal handler code is exactly the same as the execution of any other user-space code. That is to say, the kernel does not record any special state information indicating that the thread is currently executing inside a signal handler. All necessary state information is maintained in user-space registers and the user-space stack. The depth to which nested signal handlers may be invoked is thus limited only by the user-space stack (and sensible software design!).
Linux поддерживает стандартные сигналы, перечисленные далее. Во второй колонке таблицы указан стандарт (если есть), которым введён сигнал, например, «P1990» — сигнал описан в первоначальной версии стандарта POSIX.1-1990; «P2001» — сигнал добавлен в SUSv2 и POSIX.1-2001.
Сигнал | Стандарт | Действие | Комментарий |
SIGABRT | P1990 | Core | Сигнал аварии (abort), посланный abort(3) |
SIGALRM | P1990 | Term | Сигнал таймера, посланный alarm(2) |
SIGBUS | P2001 | Core | Ошибка шины (некорректный адрес доступа) |
SIGCHLD | P1990 | Ign | Потомок остановлен или завершился |
SIGCLD | - | Ign | Синоним SIGCHLD |
SIGCONT | P1990 | Cont | Продолжить, если остановлен |
SIGEMT | - | Term | Ловушка эмулятора |
SIGFPE | P1990 | Core | Ошибка операций с плавающей запятой |
SIGHUP | P1990 | Term | Обнаружен обрыв связи с управляющим |
терминалом, либо завершение управляющего терминалом процесса | |||
SIGILL | P1990 | Core | Недопустимая инструкция |
SIGINFO | - | Синоним SIGPWR | |
SIGINT | P1990 | Term | Прерывание с клавиатуры |
SIGIO | - | Term | Теперь возможен ввод/вывод (4.2BSD) |
SIGIOT | - | Core | Ловушка IOT. Синоним SIGABRT |
SIGKILL | P1990 | Term | Kill-сигнал |
SIGLOST | - | Term | Утрачена блокировка файла (не используется) |
SIGPIPE | P1990 | Term | Обрыв канала: запись в канал без |
читателей; смотрите pipe(7) | |||
SIGPOLL | P2001 | Term | Pollable event (Sys V); |
synonym for SIGIO | |||
SIGPROF | P2001 | Term | Время профилирования истекло |
SIGPWR | - | Term | Отказ питания (System V) |
SIGQUIT | P1990 | Core | Выход с клавиатуры |
SIGSEGV | P1990 | Core | Некорректная ссылка в память |
SIGSTKFLT | - | Term | Ошибка стека на сопроцессоре (не используется) |
SIGSTOP | P1990 | Stop | Остановить процесс |
SIGTSTP | P1990 | Stop | Останов введён с терминала |
SIGSYS | P2001 | Core | Неправильный системный вызов (SVr4); |
смотрите также seccomp(2) | |||
SIGTERM | P1990 | Term | Сигнал завершения |
SIGTRAP | P2001 | Core | Прерывание из-за трассировки/останова |
SIGTTIN | P1990 | Stop | Ввод с терминала для фонового процесса |
SIGTTOU | P1990 | Stop | Вывод с терминала для фонового процесса |
SIGUNUSED | - | Core | Синоним SIGSYS |
SIGURG | P2001 | Ign | Требующее внимание условие сокета (4.2BSD) |
SIGUSR1 | P1990 | Term | Определяемый пользователем сигнал 1 |
SIGUSR2 | P1990 | Term | Определяемый пользователем сигнал 2 |
SIGVTALRM | P2001 | Term | Виртуальный будильник (4.2BSD) |
SIGXCPU | P2001 | Core | Превышен предел процессорного времени (4.2BSD); |
смотрите setrlimit(2) | |||
SIGXFSZ | P2001 | Core | Превышен предел размера файла (4.2BSD); |
смотрите setrlimit(2) | |||
SIGWINCH | - | Ign | Сигнал изменения размера окна (4.3BSD, Sun) |
Сигналы SIGKILL и SIGSTOP нельзя поймать, заблокировать или проигнорировать.
В Linux до версии 2.2 включительно поведением по умолчанию для сигналов SIGSYS, SIGXCPU, SIGXFSZ и SIGBUS (на всех архитектурах кроме SPARC и MIPS) было завершение процесса без создания дампа (в некоторых системах UNIX действием по умолчанию для SIGXCPU и SIGXFSZ является завершение процесса без создания дампа). Linux версии 2.4 соответствует требованиям POSIX.1-2001 для этих сигналов и завершает процесс с созданием дампа.
Сигнал SIGEMT не определён в POSIX.1-2001, но, тем не менее, появляется почти во всех системах UNIX, где действием по умолчанию для него является завершение процесса с созданием дампа.
Сигнал SIGPWR (не определён в POSIX.1-2001) по умолчанию, обычно, игнорируется (в других системах UNIX).
Для сигнала SIGIO (не определён в POSIX.1-2001) в других системах UNIX действием по умолчанию является игнорирование.
Если несколько стандартных сигналов ожидают обработки процессом, то порядок доставки сигналов не определён.
Стандартные сигналы не упорядочиваются. Если генерируется несколько экземпляров стандартного сигнала заблокированному процессу, то только один экземпляр сигнала помечается как ожидающий (и сигнал будет доставлен только после разблокировки). В случае, если уже есть ожидающий стандартный сигнал, структура siginfo_t (смотрите sigaction(2)), связанная с этим сигналом, не перезаписывается при поступлении последующих экземпляров того же сигнала. То есть, процесс получит информацию, связанную с первым экземпляром сигнала.
Числовое значение каждого сигнала показано в таблице ниже. У многих сигналов номера различаются на разных архитектурах. Первое числовое значение в каждой строке таблицы описывает номер сигнала на x86, ARM и большинстве других архитектур; второе значение для Alpha и SPARC, третье для MIPS, последнее для PARISC. Символ минус (-) означает, что сигнал отсутствует в соответствующей архитектуре.
Сигнал | x86/ARM | Alpha/ | MIPS | PARISC | Примечания |
большинство других | SPARC | ||||
SIGHUP | 1 | 1 | 1 | 1 | |
SIGINT | 2 | 2 | 2 | 2 | |
SIGQUIT | 3 | 3 | 3 | 3 | |
SIGILL | 4 | 4 | 4 | 4 | |
SIGTRAP | 5 | 5 | 5 | 5 | |
SIGABRT | 6 | 6 | 6 | 6 | |
SIGIOT | 6 | 6 | 6 | 6 | |
SIGBUS | 7 | 10 | 10 | 10 | |
SIGEMT | - | 7 | 7 | - | |
SIGFPE | 8 | 8 | 8 | 8 | |
SIGKILL | 9 | 9 | 9 | 9 | |
SIGUSR1 | 10 | 30 | 16 | 16 | |
SIGSEGV | 11 | 11 | 11 | 11 | |
SIGUSR2 | 12 | 31 | 17 | 17 | |
SIGPIPE | 13 | 13 | 13 | 13 | |
SIGALRM | 14 | 14 | 14 | 14 | |
SIGTERM | 15 | 15 | 15 | 15 | |
SIGSTKFLT | 16 | - | - | 7 | |
SIGCHLD | 17 | 20 | 18 | 18 | |
SIGCLD | - | - | 18 | - | |
SIGCONT | 18 | 19 | 25 | 26 | |
SIGSTOP | 19 | 17 | 23 | 24 | |
SIGTSTP | 20 | 18 | 24 | 25 | |
SIGTTIN | 21 | 21 | 26 | 27 | |
SIGTTOU | 22 | 22 | 27 | 28 | |
SIGURG | 23 | 16 | 21 | 29 | |
SIGXCPU | 24 | 24 | 30 | 12 | |
SIGXFSZ | 25 | 25 | 31 | 30 | |
SIGVTALRM | 26 | 26 | 28 | 20 | |
SIGPROF | 27 | 27 | 29 | 21 | |
SIGWINCH | 28 | 28 | 20 | 23 | |
SIGIO | 29 | 23 | 22 | 22 | |
SIGPOLL | Тот же, что SIGIO | ||||
SIGPWR | 30 | 29/- | 19 | 19 | |
SIGINFO | - | 29/- | - | - | |
SIGLOST | - | -/29 | - | - | |
SIGSYS | 31 | 12 | 12 | 31 | |
SIGUNUSED | 31 | - | - | 31 |
Также заметим следующее:
Starting with Linux 2.2, Linux supports real-time signals as originally defined in the POSIX.1b real-time extensions (and now included in POSIX.1-2001). The range of supported real-time signals is defined by the macros SIGRTMIN and SIGRTMAX. POSIX.1-2001 requires that an implementation support at least _POSIX_RTSIG_MAX (8) real-time signals.
Ядро Linux поддерживает 33 таких сигнала, начиная с номера 32 до номера 64. Однако внутри реализации нитей POSIX в glibc используется два (для NPTL) или три (для LinuxThreads) сигнала реального времени (смотрите pthreads(7)), а значение SIGRTMIN корректируется должным образом (до 34 или 35). Так как диапазон доступных сигналов реального времени различается в зависимости от реализации нитей в glibc (и это может происходить во время выполнения при смене ядра и glibc), и, более того, диапазон сигналов реального времени различен в разных системах UNIX, то программы никогда не должны задавать сигналы реального времени по номерам, а вместо этого всегда должны записывать их в виде SIGRTMIN+n и выполнять проверку (во время выполнения), что SIGRTMIN+n не превышает SIGRTMAX.
В отличие от стандартных сигналов, сигналы реального времени не имеют предопределенного назначения: весь набор сигналов реального времени приложения могут использовать так, как им нужно.
Действием по умолчанию для необработанных сигналов реального времени является завершение процесса (terminate).
Сигналы реального времени отличаются от обычных в следующем:
Если процессу передан и стандартный сигнал, и сигнал реального времени, то в POSIX однозначно не определено, какой из них будет доставлен первым. В Linux, как и во многих других реализациях в таких случаях, отдан приоритет стандартным сигналам.
According to POSIX, an implementation should permit at least _POSIX_SIGQUEUE_MAX (32) real-time signals to be queued to a process. However, Linux does things differently. Up to and including Linux 2.6.7, Linux imposes a system-wide limit on the number of queued real-time signals for all processes. This limit can be viewed and (with privilege) changed via the /proc/sys/kernel/rtsig-max file. A related file, /proc/sys/kernel/rtsig-nr, can be used to find out how many real-time signals are currently queued. In Linux 2.6.8, these /proc interfaces were replaced by the RLIMIT_SIGPENDING resource limit, which specifies a per-user limit for queued signals; see setrlimit(2) for further details.
Для дополнительных сигналов реального времени требуется расширение структуры набора сигналов (sigset_t) с 32 до 64 бит. В связи с этим, различные системные вызовы заменены на новые системные вызов, поддерживающие набор сигналов большего размера. Вот соответствие старых и новых системных вызовов:
Linux версии 2.0 и более ранние | Linux версии 2.2 и новее |
sigaction(2) | rt_sigaction(2) |
sigpending(2) | rt_sigpending(2) |
sigprocmask(2) | rt_sigprocmask(2) |
sigreturn(2) | rt_sigreturn(2) |
sigsuspend(2) | rt_sigsuspend(2) |
sigtimedwait(2) | rt_sigtimedwait(2) |
Если обработчик сигнала вызван во время заблокированного системного вызова или библиотечной функции, то может произойти следующее:
Выбираемое поведение зависит от интерфейса и от того, был ли обработчик сигнала установлен с флагом SA_RESTART (смотрите sigaction(2)). Но в различных системах UNIX есть другие различия; далее описаны подробности для Linux.
Если заблокированный вызов к одному из следующих интерфейсов прерван обработчиком сигнала, то вызов автоматически перезапускается после завершения обработчика сигнала, если задействован флаг SA_RESTART; иначе вызов завершается ошибкой EINTR:
Следующие интерфейсы никогда не перезапускаются после прерывания обработчиком сигнала независимо от наличия SA_RESTART; они всегда завершаются с ошибкой EINTR, если прерываются обработчиком сигнала:
Функция sleep(3) также никогда не перезапускается, если прервана обработчиком сигнала, но сообщает об успешном выполнении: возвращает количество оставшиеся для сна секунд.
In certain circumstances, the seccomp(2) user-space notification feature can lead to restarting of system calls that would otherwise never be restarted by SA_RESTART; for details, see seccomp_unotify(2).
В Linux, даже в отсутствии обработчиков сигнала, некоторые блокирующие интерфейсы могут завершаться с ошибкой EINTR, если процесс останавливается одним из сигналов останова и затем возобновляет работу при получении сигнала SIGCONT. Такое поведение не предусмотрено POSIX.1 и в других системах отсутствует.
Интерфейсы Linux, к которым это относится:
POSIX.1, кроме описанных исключений.
Описание безопасных асинхронных функций при работе с сигналами смотрите в signal-safety(7).
В файле /proc/[pid]/task/[tid]/status содержатся различные поля о сигналах, которые нить блокирует (SigBlk), ловит (SigCgt) или игнорирует (SigIgn). Набор отлавливаемые или игнорируемых сигналов одинаков для всех нитей процесса. Остальные поля отражают набор ожидающих сигналов, которые непосредственно направляются нити (SigPnd), а также набор ожидающих сигналов, которые направляются непосредственно процессу (ShdPnd). Соответствующие поля в /proc/[pid]/status содержат информацию для главной нити. Дополнительную информацию смотрите в proc(5).
There are six signals that can be delivered as a consequence of a hardware exception: SIGBUS, SIGEMT, SIGFPE, SIGILL, SIGSEGV, and SIGTRAP. Which of these signals is delivered, for any given hardware exception, is not documented and does not always make sense.
For example, an invalid memory access that causes delivery of SIGSEGV on one CPU architecture may cause delivery of SIGBUS on another architecture, or vice versa.
For another example, using the x86 int instruction with a forbidden argument (any number other than 3 or 128) causes delivery of SIGSEGV, even though SIGILL would make more sense, because of how the CPU reports the forbidden operation to the kernel.
kill(1), clone(2), getrlimit(2), kill(2), pidfd_send_signal(2), restart_syscall(2), rt_sigqueueinfo(2), setitimer(2), setrlimit(2), sgetmask(2), sigaction(2), sigaltstack(2), signal(2), signalfd(2), sigpending(2), sigprocmask(2), sigreturn(2), sigsuspend(2), sigwaitinfo(2), abort(3), bsd_signal(3), killpg(3), longjmp(3), pthread_sigqueue(3), raise(3), sigqueue(3), sigset(3), sigsetops(3), sigvec(3), sigwait(3), strsignal(3), swapcontext(3), sysv_signal(3), core(5), proc(5), nptl(7), pthreads(7), sigevent(7)
Русский перевод этой страницы руководства был сделан Alexander Golubev <fatzer2@gmail.com>, Azamat Hackimov <azamat.hackimov@gmail.com>, Hotellook, Nikita <zxcvbnm3230@mail.ru>, Spiros Georgaras <sng@hellug.gr>, Vladislav <ivladislavefimov@gmail.com>, Yuri Kozlov <yuray@komyakino.ru> и Иван Павлов <pavia00@gmail.com>
Этот перевод является бесплатной документацией; прочитайте Стандартную общественную лицензию GNU версии 3 или более позднюю, чтобы узнать об условиях авторского права. Мы не несем НИКАКОЙ ОТВЕТСТВЕННОСТИ.
Если вы обнаружите ошибки в переводе этой страницы руководства, пожалуйста, отправьте электронное письмо на man-pages-ru-talks@lists.sourceforge.net.
5 февраля 2023 г. | Linux man-pages 6.03 |