.\" -*- coding: UTF-8 -*- '\" t .\" Copyright (c) 1993 by Thomas Koenig (ig25@rz.uni-karlsruhe.de) .\" and Copyright (c) 2002, 2006, 2020 by Michael Kerrisk .\" and Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk .\" .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" Modified Sat Jul 24 17:34:08 1993 by Rik Faith (faith@cs.unc.edu) .\" Modified Sun Jan 7 01:41:27 1996 by Andries Brouwer (aeb@cwi.nl) .\" Modified Sun Apr 14 12:02:29 1996 by Andries Brouwer (aeb@cwi.nl) .\" Modified Sat Nov 13 16:28:23 1999 by Andries Brouwer (aeb@cwi.nl) .\" Modified 10 Apr 2002, by Michael Kerrisk .\" Modified 7 Jun 2002, by Michael Kerrisk .\" Added information on real-time signals .\" Modified 13 Jun 2002, by Michael Kerrisk .\" Noted that SIGSTKFLT is in fact unused .\" 2004-12-03, Modified mtk, added notes on RLIMIT_SIGPENDING .\" 2006-04-24, mtk, Added text on changing signal dispositions, .\" signal mask, and pending signals. .\" 2008-07-04, mtk: .\" Added section on system call restarting (SA_RESTART) .\" Added section on stop/cont signals interrupting syscalls. .\" 2008-10-05, mtk: various additions .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH signal 7 "17 июня 2024 г." "Справочные страницы Linux 6.9.1" .SH ИМЯ signal \- обзор сигналов .SH ОПИСАНИЕ В Linux поддерживаются надёжные (reliable) сигналы POSIX (далее, «стандартные сигналы») и сигналы реального времени POSIX. .SS "Обработчики сигнала" Каждый сигнал имеет текущий \fIобработчик\fP, который определяет, что будет делать процесс при поступлении сигнала. .P В таблице далее есть столбец «Действие», в котором указан обработчик по умолчанию для каждого сигнала: .TP Term Действие по умолчанию — завершение процесса. .TP Ign Действие по умолчанию — игнорирование сигнала. .TP Core Действие по умолчанию — завершение процесса и вывод дампа в файл (смотрите \fBcore\fP(5)). .TP Stop Действие по умолчанию — остановка процесса. .TP Cont Действие по умолчанию — продолжение работы процесса, если он в данный момент остановлен. .P Процесс может изменить обработчик сигнала с помощью \fBsigaction\fP(2) или \fBsignal\fP(2) (последний менее переносим, если используется для установки обработчика сигнала; дополнительную информацию смотрите в \fBsignal\fP(2)). Используя данные системные вызовы процесс может выбрать одно из следующих действий при получении сигнала: выполнить действие по умолчанию, игнорировать сигнал, поймать сигнал \fIобработчиком сигнала\fP — функцией, задаваемой программистом, которая автоматически вызывается при получении сигнала. .P По умолчанию обработчик сигнала использует обычный стек процесса. Возможно сделать так, чтобы обработчик сигнала использовал альтернативный стек; как это делается и когда это может быть полезно смотрите в \fBsigaltstack\fP(2). .P Реакция на сигналы является атрибутом процесса: в многонитевом приложении реакция на определённый сигнал одинакова для всех нитей. .P Потомок, созданный с помощью \fBfork\fP(2), наследует реакцию на сигналы от своего родителя. При \fBexecve\fP(2) реакция на сигналы устанавливается в значение по умолчанию; реакция на игнорируемые сигналы не изменяется. .SS "Отправка сигнала" Для отправки сигнала можно использовать следующие системные вызовы и библиотечные функции: .TP \fBraise\fP(3) Посылает сигнал вызвавшей нити. .TP \fBkill\fP(2) Посылает сигнал указанному процессу, всем членам указанной группы процессов или всем процессам в системе. .TP \fBpidfd_send_signal\fP(2) Sends a signal to a process identified by a PID file descriptor. .TP \fBkillpg\fP(3) Посылает сигнал всем членам указанной группы процессов. .TP \fBpthread_kill\fP(3) Посылает сигнал указанной нити POSIX в том же процессе, что и вызывающий. .TP \fBtgkill\fP(2) Посылает сигнал указанной нити в указанном процессе (данный системный вызов используется в реализации \fBpthread_kill\fP(3)). .TP \fBsigqueue\fP(3) Посылает сигнал реального времени указанному процессу с сопроводительными данными. .SS "Ожидание сигнала для обработки" Следующие системные вызовы приостанавливают выполнение вызывающей нити до тех пор, пока не будет пойман сигнал (или необработанный сигнал не завершит процесс): .TP \fBpause\fP(2) Приостанавливает выполнение до тех пор, пока не будет пойман любой сигнал. .TP \fBsigsuspend\fP(2) .\" Временно изменяет маску сигналов (смотрите далее) и приостанавливает выполнение до получения одного из незамаскированных сигналов. .SS "Синхронный приём сигнала" В отличие от асинхронного получения сигнала через обработчик, возможно синхронно получить сигнал, то есть блокировать выполнение до поступления сигнала в некоторой точке, в которой ядро вернёт информацию о сигнале вызывающему. Для этого существует два пути: .IP \[bu] 3 С помощью \fBsigwaitinfo\fP(2), \fBsigtimedwait\fP(2) и \fBsigwait\fP(3). Они приостанавливают выполнение до поступления одного из заданного набора сигналов. Каждый из этих вызовов возвращает информацию о полученном сигнале. .IP \[bu] С помощью \fBsignalfd\fP(2). Данный вызов возвращает файловый дескриптор, который можно использовать для чтения информации о сигналах, доставляемых вызывающему. Каждое выполнение \fBread\fP(2) с этим файловым дескриптором блокируется до тех пор, пока один из сигналов набора, указанного в вызове \fBsignalfd\fP(2), не будет послан вызывающему. В возвращаемом \fBread\fP(2) буфере содержится структура, описывающая сигнал. .SS "Сигнальная маска и ожидающие сигналы" Сигнал может быть \fIзаблокирован\fP. Это означает, что он не будет доставлен до тех пор, пока не будет разблокирован. В промежуток времени от генерации сигнала и до его доставки о сигнале говорят как об \fIожидающем\fP. .P В каждой нити процесса имеется независимая \fIсигнальная маска\fP, определяющая набор сигналов, которые нить, в данный момент, блокирует. Нить может управлять сигнальной маской с помощью \fBpthread_sigmask\fP(3). В обычном однонитевом приложении для работы с сигнальной маской можно использовать вызов \fBsigprocmask\fP(2). .P Потомок, создаваемый с помощью \fBfork\fP(2), наследует копию родительской маски сигналов; маска сигналов сохраняется при вызове \fBexecve\fP(2). .P 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 \fBkill\fP(2) or \fBsigqueue\fP(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., \fBSIGSEGV\fP for an invalid memory access, or \fBSIGFPE\fP for a math error), or because it was targeted at a specific thread using interfaces such as \fBtgkill\fP(2) or \fBpthread_kill\fP(3). .P .\" Joseph C. Sible notes: .\" On Linux, if the main thread has the signal unblocked, then the kernel .\" will always deliver the signal there, citing this kernel code .\" .\" Per this comment in kernel/signal.c since time immemorial: .\" .\" /* .\" * Now find a thread we can wake up to take the signal off the queue. .\" * .\" * If the main thread wants the signal, it gets first crack. .\" * Probably the least surprising to the average bear. .\" */ .\" .\" But this does not mean the signal will be delivered only in the .\" main thread, since if a handler is already executing in the main thread .\" (and thus the signal is blocked in that thread), then a further .\" might be delivered in a different thread. .\" Направленный процессу сигнал может быть доставлен в любую из нитей, у которой сигнал не заблокирован. Если имеется несколько таких нитей, то ядро выбирает произвольную нить, которой и доставит сигнал. .P Нить может получить набор сигналов, которые находятся в состоянии ожидания с помощью вызова \fBsigpending\fP(2). Этот набор будет состоять из объединения набора ожидающих сигналов, направленных процессу, и набора ожидающих сигналов для вызвавшей нити. .P .\" Потомок, созданный с помощью \fBfork\fP(2), первоначально имеет пустой набор ожидающих сигналов; набор ожидающих сигналов сохраняется при вызове \fBexecve\fP(2). .SS "Execution of signal handlers" 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: .IP (1) 5 The kernel performs the necessary preparatory steps for execution of the signal handler: .RS .IP (1.1) 7 The signal is removed from the set of pending signals. .IP (1.2) If the signal handler was installed by a call to \fBsigaction\fP(2) that specified the \fBSA_ONSTACK\fP flag and the thread has defined an alternate signal stack (using \fBsigaltstack\fP(2)), then that stack is installed. .IP (1.3) Various pieces of signal\-related context are saved into a special frame that is created on the stack. The saved information includes: .RS .IP \[bu] 3 the program counter register (i.e., the address of the next instruction in the main program that should be executed when the signal handler returns); .IP \[bu] architecture\-specific register state required for resuming the interrupted program; .IP \[bu] the thread's current signal mask; .IP \[bu] the thread's alternate signal stack settings. .RE .IP If the signal handler was installed using the \fBsigaction\fP(2) \fBSA_SIGINFO\fP flag, then the above information is accessible via the \fIucontext_t\fP object that is pointed to by the third argument of the signal handler. This object reflects the state at which the signal is delivered, rather than in the handler; for example, the mask of blocked signals stored in this object will not contain the mask of new signals blocked through \fBsigaction\fP(2). .IP (1.4) Any signals specified in \fIact\->sa_mask\fP when registering the handler with \fBsigaction\fP(2) are added to the thread's signal mask. The signal being delivered is also added to the signal mask, unless \fBSA_NODEFER\fP was specified when registering the handler. These signals are thus blocked while the handler executes. .RE .IP (2) The kernel constructs a frame for the signal handler on the stack. The kernel sets the program counter for the thread to point to the first instruction of the signal handler function, and configures the return address for that function to point to a piece of user\-space code known as the signal trampoline (described in \fBsigreturn\fP(2)). .IP (3) The kernel passes control back to user\-space, where execution commences at the start of the signal handler function. .IP (4) When the signal handler returns, control passes to the signal trampoline code. .IP (5) The signal trampoline calls \fBsigreturn\fP(2), a system call that uses the information in the stack frame created in step 1 to restore the thread to its state before the signal handler was called. The thread's signal mask and alternate signal stack settings are restored as part of this procedure. Upon completion of the call to \fBsigreturn\fP(2), the kernel transfers control back to user space, and the thread recommences execution at the point where it was interrupted by the signal handler. .P Note that if the signal handler does not return (e.g., control is transferred out of the handler using \fBsiglongjmp\fP(3), or the handler executes a new program with \fBexecve\fP(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 \fBsigprocmask\fP(2)), if it is desired to unblock the signals that were blocked on entry to the signal handler. (Note that \fBsiglongjmp\fP(3) may or may not restore the signal mask, depending on the \fIsavesigs\fP value that was specified in the corresponding call to \fBsigsetjmp\fP(3).) .P .\" 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!). .SS "Стандартные сигналы" Linux поддерживает стандартные сигналы, перечисленные далее. Во второй колонке таблицы указан стандарт (если есть), которым введён сигнал, например, «P1990» — сигнал описан в первоначальной версии стандарта POSIX.1\-1990; «P2001» — сигнал добавлен в SUSv2 и POSIX.1\-2001. .TS l c c l ____ lB c c l. Сигнал Стандарт Действие Комментарий SIGABRT P1990 Core Сигнал аварии (abort), посланный \fBabort\fP(3) SIGALRM P1990 Term Сигнал таймера, посланный \fBalarm\fP(2) SIGBUS P2001 Core Ошибка шины (некорректный адрес доступа) SIGCHLD P1990 Ign Потомок остановлен или завершился SIGCLD \- Ign Синоним \fBSIGCHLD\fP SIGCONT P1990 Cont Продолжить, если остановлен SIGEMT \- Term Ловушка эмулятора SIGFPE P1990 Core Ошибка операций с плавающей запятой SIGHUP P1990 Term Обнаружен обрыв связи с управляющим терминалом, либо завершение управляющего терминалом процесса SIGILL P1990 Core Недопустимая инструкция SIGINFO \- Синоним \fBSIGPWR\fP SIGINT P1990 Term Прерывание с клавиатуры SIGIO \- Term Теперь возможен ввод/вывод (4.2BSD) SIGIOT \- Core Ловушка IOT. Синоним \fBSIGABRT\fP SIGKILL P1990 Term Kill\-сигнал SIGLOST \- Term Утрачена блокировка файла (не используется) SIGPIPE P1990 Term Обрыв канала: запись в канал без читателей; смотрите \fBpipe\fP(7) SIGPOLL P2001 Term Pollable event (Sys V); synonym for \fBSIGIO\fP 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); смотрите также \fBseccomp\fP(2) SIGTERM P1990 Term Сигнал завершения SIGTRAP P2001 Core Прерывание из\-за трассировки/останова SIGTTIN P1990 Stop Ввод с терминала для фонового процесса SIGTTOU P1990 Stop Вывод с терминала для фонового процесса SIGUNUSED \- Core Синоним \fBSIGSYS\fP SIGURG P2001 Ign Требующее внимание условие сокета (4.2BSD) SIGUSR1 P1990 Term Определяемый пользователем сигнал 1 SIGUSR2 P1990 Term Определяемый пользователем сигнал 2 SIGVTALRM P2001 Term Виртуальный будильник (4.2BSD) SIGXCPU P2001 Core Превышен предел процессорного времени (4.2BSD); смотрите \fBsetrlimit\fP(2) SIGXFSZ P2001 Core Превышен предел размера файла (4.2BSD); смотрите \fBsetrlimit\fP(2) SIGWINCH \- Ign Сигнал изменения размера окна (4.3BSD, Sun) .TE .P Сигналы \fBSIGKILL\fP и \fBSIGSTOP\fP нельзя поймать, заблокировать или проигнорировать. .P В Linux до версии 2.2 включительно поведением по умолчанию для сигналов \fBSIGSYS\fP, \fBSIGXCPU\fP, \fBSIGXFSZ\fP и \fBSIGBUS\fP (на всех архитектурах кроме SPARC и MIPS) было завершение процесса без создания дампа (в некоторых системах UNIX действием по умолчанию для \fBSIGXCPU\fP и \fBSIGXFSZ\fP является завершение процесса без создания дампа). Linux версии 2.4 соответствует требованиям POSIX.1\-2001 для этих сигналов и завершает процесс с созданием дампа. .P Сигнал \fBSIGEMT\fP не определён в POSIX.1\-2001, но, тем не менее, появляется почти во всех системах UNIX, где действием по умолчанию для него является завершение процесса с созданием дампа. .P Сигнал \fBSIGPWR\fP (не определён в POSIX.1\-2001) по умолчанию, обычно, игнорируется (в других системах UNIX). .P .\" Для сигнала \fBSIGIO\fP (не определён в POSIX.1\-2001) в других системах UNIX действием по умолчанию является игнорирование. .SS "Семантика очерёдности и доставки стандартных сигналов" Если несколько стандартных сигналов ожидают обработки процессом, то порядок доставки сигналов не определён. .P .\" Стандартные сигналы не упорядочиваются. Если генерируется несколько экземпляров стандартного сигнала заблокированному процессу, то только один экземпляр сигнала помечается как ожидающий (и сигнал будет доставлен только после разблокировки). В случае, если уже есть ожидающий стандартный сигнал, структура \fIsiginfo_t\fP (смотрите \fBsigaction\fP(2)), связанная с этим сигналом, не перезаписывается при поступлении последующих экземпляров того же сигнала. То есть, процесс получит информацию, связанную с первым экземпляром сигнала. .SS "Нумерация стандартных сигналов" Числовое значение каждого сигнала показано в таблице ниже. У многих сигналов номера различаются на разных архитектурах. Первое числовое значение в каждой строке таблицы описывает номер сигнала на x86, ARM и большинстве других архитектур; второе значение для Alpha и SPARC, третье для MIPS, последнее для PARISC. Символ минус (\-) означает, что сигнал отсутствует в соответствующей архитектуре. .TS l c c c c l l c c c c l ______ lB c c c c l. Сигнал x86/ARM Alpha/ MIPS PARISC Примечания большинство других SPARC SIGHUP \01 \01 \01 \01 SIGINT \02 \02 \02 \02 SIGQUIT \03 \03 \03 \03 SIGILL \04 \04 \04 \04 SIGTRAP \05 \05 \05 \05 SIGABRT \06 \06 \06 \06 SIGIOT \06 \06 \06 \06 SIGBUS \07 10 10 10 SIGEMT \- \07 \07 \- SIGFPE \08 \08 \08 \08 SIGKILL \09 \09 \09 \09 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 \- \- \07 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 .TE .P Также заметим следующее: .IP \[bu] 3 Если определён сигнал \fBSIGUNUSED\fP, то он является синонимом \fBSIGSYS\fP. Начиная с glibc 2.26, определение \fBSIGUNUSED\fP удалено из всех архитектур. .IP \[bu] .\" Сигнал с номером 29 на Alpha соответствует \fBSIGINFO\fP/\fBSIGPWR\fP (одинаковый номер), а на SPARC соответствует \fBSIGLOST\fP. .SS "Сигналы реального времени" 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 \fBSIGRTMIN\fP and \fBSIGRTMAX\fP. POSIX.1\-2001 requires that an implementation support at least \fB_POSIX_RTSIG_MAX\fP (8) real\-time signals. .P Ядро Linux поддерживает 33 таких сигнала, начиная с номера 32 до номера 64. Однако внутри реализации нитей POSIX в glibc используется два (для NPTL) или три (для LinuxThreads) сигнала реального времени (смотрите \fBpthreads\fP(7)), а значение \fBSIGRTMIN\fP корректируется должным образом (до 34 или 35). Так как диапазон доступных сигналов реального времени различается в зависимости от реализации нитей в glibc (и это может происходить во время выполнения при смене ядра и glibc), и, более того, диапазон сигналов реального времени различен в разных системах UNIX, то программы \fIникогда не должны задавать сигналы реального времени по номерам\fP, а вместо этого всегда должны записывать их в виде \fBSIGRTMIN\fP+n и выполнять проверку (во время выполнения), что \fBSIGRTMIN\fP+n не превышает \fBSIGRTMAX\fP. .P В отличие от стандартных сигналов, сигналы реального времени не имеют предопределенного назначения: весь набор сигналов реального времени приложения могут использовать так, как им нужно. .P Действием по умолчанию для необработанных сигналов реального времени является завершение процесса (terminate). .P Сигналы реального времени отличаются от обычных в следующем: .IP \[bu] 3 В очередь можно добавлять несколько экземпляров одного сигнала реального времени. В случае со стандартными сигналами, если доставляется несколько экземпляров сигнала, в то время как этот тип сигнала в данный момент заблокирован, то только один экземпляр будет добавлен в очередь. .IP \[bu] Если сигнал отправляется с помощью \fBsigqueue\fP(3), то с сигналом может быть отправлено некоторое значение (целочисленное, либо указатель). Если принимающий процесс устанавливает обработчик для сигнала, используя флаг \fBSA_SIGINFO\fP и вызов \fBsigaction\fP(2), то он может получить это значение через поле \fIsi_value\fP структуры \fIsiginfo_t\fP, переданной обработчику в виде второго аргумента. Кроме этого, поля \fIsi_pid\fP и \fIsi_uid\fP данной структуры можно использовать для получения идентификатора процесса и реального идентификатора пользователя, отправившего сигнал. .IP \[bu] Сигналы реального времени доставляются точно в порядке поступления. Несколько сигналов одного типа доставляются в порядке, определяемых их отправлением. Если процессу отправлено несколько разных сигналов реального времени, то порядок их доставки начинается с сигнала с наименьшим номером (то есть сигналы с наименьшим номером имеют наивысший приоритет). Порядок же для стандартных сигналов в такой ситуации не определён. .P Если процессу передан и стандартный сигнал, и сигнал реального времени, то в POSIX однозначно не определено, какой из них будет доставлен первым. В Linux, как и во многих других реализациях в таких случаях, отдан приоритет стандартным сигналам. .P According to POSIX, an implementation should permit at least \fB_POSIX_SIGQUEUE_MAX\fP (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 \fI/proc/sys/kernel/rtsig\-max\fP file. A related file, \fI/proc/sys/kernel/rtsig\-nr\fP, can be used to find out how many real\-time signals are currently queued. In Linux 2.6.8, these \fI/proc\fP interfaces were replaced by the \fBRLIMIT_SIGPENDING\fP resource limit, which specifies a per\-user limit for queued signals; see \fBsetrlimit\fP(2) for further details. .P Для дополнительных сигналов реального времени требуется расширение структуры набора сигналов (\fIsigset_t\fP) с 32 до 64 бит. В связи с этим, различные системные вызовы заменены на новые системные вызов, поддерживающие набор сигналов большего размера. Вот соответствие старых и новых системных вызовов: .TS lb lb l l. Linux версии 2.0 и более ранние Linux версии 2.2 и новее \fBsigaction\fP(2) \fBrt_sigaction\fP(2) \fBsigpending\fP(2) \fBrt_sigpending\fP(2) \fBsigprocmask\fP(2) \fBrt_sigprocmask\fP(2) \fBsigreturn\fP(2) \fBrt_sigreturn\fP(2) \fBsigsuspend\fP(2) \fBrt_sigsuspend\fP(2) \fBsigtimedwait\fP(2) \fBrt_sigtimedwait\fP(2) .TE .\" .SS "Прерывание системных вызовов и библиотечных функций обработчиками сигналов" Если обработчик сигнала вызван во время заблокированного системного вызова или библиотечной функции, то может произойти следующее: .IP \[bu] 3 вызов автоматически перезапускается после возврата из обработчика сигнала; или .IP \[bu] вызов завершается с ошибкой \fBEINTR\fP. .P Выбираемое поведение зависит от интерфейса и от того, был ли обработчик сигнала установлен с флагом \fBSA_RESTART\fP (смотрите \fBsigaction\fP(2)). Но в различных системах UNIX есть другие различия; далее описаны подробности для Linux. .P .\" The following system calls use ERESTARTSYS, .\" so that they are restartable Если заблокированный вызов к одному из следующих интерфейсов прерван обработчиком сигнала, то вызов автоматически перезапускается после завершения обработчика сигнала, если задействован флаг \fBSA_RESTART\fP; иначе вызов завершается ошибкой \fBEINTR\fP: .IP \[bu] 3 Вызовы \fBread\fP(2), \fBreadv\fP(2), \fBwrite\fP(2), \fBwritev\fP(2) и \fBioctl\fP(2) для «медленных» устройств. «Медленным» называют устройство, которое может навсегда заблокировать ввод\-вывод, например, терминал, канал или сокет. Если вызов ввода\-вывода для медленного устройства уже передал немного данных на момент прерывания обработчиком сигнала, то вызов вернёт состояние успешного выполнения (обычно, количество переданных байт). Заметим, что диск (локальный) не подходит под определение медленного устройства; операции ввода\-вывода с дисками не прерываются сигналами. .IP \[bu] Вызов \fBopen\fP(2), если он может выполнить блокировку (например, при открытии FIFO; смотрите \fBfifo\fP(7)). .IP \[bu] Вызовы \fBwait\fP(2), \fBwait3\fP(2), \fBwait4\fP(2), \fBwaitid\fP(2) и \fBwaitpid\fP(2). .IP \[bu] .\" If a timeout (setsockopt()) is in effect on the socket, then these .\" system calls switch to using EINTR. Consequently, they and are not .\" automatically restarted, and they show the stop/cont behavior .\" described below. (Verified from Linux 2.6.26 source, and by experiment; mtk) .\" FIXME What about sendmmsg()? Интерфейсы сокетов: \fBaccept\fP(2), \fBconnect\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2), \fBrecvmsg\fP(2), \fBsend\fP(2), \fBsendto\fP(2) и \fBsendmsg\fP(2), если для сокета не указано время ожидания (смотрите далее). .IP \[bu] Интерфейсы файловой блокировки: \fBflock\fP(2) и операции \fBF_SETLKW\fP и \fBF_OFD_SETLKW\fP у \fBfcntl\fP(2). .IP \[bu] Интерфейсы очереди сообщений POSIX: \fBmq_receive\fP(3), \fBmq_timedreceive\fP(3), \fBmq_send\fP(3) и \fBmq_timedsend\fP(3). .IP \[bu] .\" commit 72c1bbf308c75a136803d2d76d0e18258be14c7a Вызов \fBfutex\fP(2) с \fBFUTEX_WAIT\fP (начиная с Linux 2.6.22; до этой версии вызов завершался с ошибкой \fBEINTR\fP). .IP \[bu] \fBgetrandom\fP(2). .IP \[bu] \fBpthread_mutex_lock\fP(3), \fBpthread_cond_wait\fP(3) связанный с этим программный интерфейс. .IP \[bu] \fBfutex\fP(2) \fBFUTEX_WAIT_BITSET\fP. .IP \[bu] .\" as a consequence of the 2.6.22 changes in the futex() implementation Интерфейсы семафоров POSIX: \fBsem_wait\fP(3) и \fBsem_timedwait\fP(3) (начиная с Linux 2.6.22; до этой версии вызовы завершались с ошибкой \fBEINTR\fP). .IP \[bu] .\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06 Вызов \fBread\fP(2) из файлового дескриптора \fBinotify\fP(7) (начиная с Linux 3.8; прежде всегда завершался с ошибкой \fBEINTR\fP). .P .\" These are the system calls that give EINTR or ERESTARTNOHAND .\" on interruption by a signal handler. Следующие интерфейсы никогда не перезапускаются после прерывания обработчиком сигнала независимо от наличия \fBSA_RESTART\fP; они всегда завершаются с ошибкой \fBEINTR\fP, если прерываются обработчиком сигнала: .IP \[bu] 3 «Входные» интерфейсы сокетов, если установлен таймаут (\fBSO_RCVTIMEO\fP) на сокете с помощью \fBsetsockopt\fP(2): \fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2) (также с аргументом \fItimeout\fP, не равным NULL) и \fBrecvmsg\fP(2). .IP \[bu] .\" FIXME What about sendmmsg()? «Выходные» интерфейсы сокетов, если установлен таймаут (\fBSO_RCVTIMEO\fP) на сокете с помощью \fBsetsockopt\fP(2): \fBconnect\fP(2), \fBsend\fP(2), \fBsendto\fP(2) и \fBsendmsg\fP(2). .IP \[bu] Интерфейсы, используемые для ожидания сигналов: \fBpause\fP(2), \fBsigsuspend\fP(2), \fBsigtimedwait\fP(2) и \fBsigwaitinfo\fP(2). .IP \[bu] Интерфейсы комбинирования (multiplexing) файловых дескрипторов: \fBepoll_wait\fP(2), \fBepoll_pwait\fP(2), \fBpoll\fP(2), \fBppoll\fP(2), \fBselect\fP(2) и \fBpselect\fP(2). .IP \[bu] .\" On some other systems, SA_RESTART does restart these system calls IPC\-интерфейсы System V: \fBmsgrcv\fP(2), \fBmsgsnd\fP(2), \fBsemop\fP(2) и \fBsemtimedop\fP(2). .IP \[bu] Интерфейсы сна: \fBclock_nanosleep\fP(2), \fBnanosleep\fP(2) и \fBusleep\fP(3). .IP \[bu] \fBio_getevents\fP(2). .P Функция \fBsleep\fP(3) также никогда не перезапускается, если прервана обработчиком сигнала, но сообщает об успешном выполнении: возвращает количество оставшиеся для сна секунд. .P .\" In certain circumstances, the \fBseccomp\fP(2) user\-space notification feature can lead to restarting of system calls that would otherwise never be restarted by \fBSA_RESTART\fP; for details, see \fBseccomp_unotify\fP(2). .SS "Прерывание системных вызовов и библиотечных функций сигналами останова" В Linux, даже в отсутствии обработчиков сигнала, некоторые блокирующие интерфейсы могут завершаться с ошибкой \fBEINTR\fP, если процесс останавливается одним из сигналов останова и затем возобновляет работу при получении сигнала \fBSIGCONT\fP. Такое поведение не предусмотрено POSIX.1 и в других системах отсутствует. .P Интерфейсы Linux, к которым это относится: .IP \[bu] 3 «Входные» интерфейсы сокетов, если установлен таймаут (\fBSO_RCVTIMEO\fP) на сокете с помощью \fBsetsockopt\fP(2): \fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2) (также с аргументом \fItimeout\fP, не равным NULL) и \fBrecvmsg\fP(2). .IP \[bu] .\" FIXME What about sendmmsg()? «Выходные» интерфейсы сокетов, если установлен таймаут (\fBSO_RCVTIMEO\fP) на сокете с помощью \fBsetsockopt\fP(2): \fBconnect\fP(2), \fBsend\fP(2), \fBsendto\fP(2) и \fBsendmsg\fP(2), если установлен таймаут отправления (\fBSO_SNDTIMEO\fP). .IP \[bu] \fBepoll_wait\fP(2), \fBepoll_pwait\fP(2). .IP \[bu] \fBsemop\fP(2), \fBsemtimedop\fP(2). .IP \[bu] \fBsigtimedwait\fP(2), \fBsigwaitinfo\fP(2). .IP \[bu] .\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06 Linux 3.7 и старее: \fBread\fP(2) из файлового дескриптора \fBinotify\fP(7) .IP \[bu] Linux версии 2.6.21 и более ранних: \fBfutex\fP(2) с \fBFUTEX_WAIT\fP, \fBsem_timedwait\fP(3), \fBsem_wait\fP(3). .IP \[bu] Linux версии 2.6.8 и более ранних: \fBmsgrcv\fP(2), \fBmsgsnd\fP(2). .IP \[bu] Linux версии 2.4 и более ранних: \fBnanosleep\fP(2). .SH СТАНДАРТЫ POSIX.1, кроме описанных исключений. .SH ПРИМЕЧАНИЯ Описание безопасных асинхронных функций при работе с сигналами смотрите в \fBsignal\-safety\fP(7). .P The \fI/proc/\fPpid\fI/task/\fPtid\fI/status\fP file contains various fields that show the signals that a thread is blocking (\fISigBlk\fP), catching (\fISigCgt\fP), or ignoring (\fISigIgn\fP). (The set of signals that are caught or ignored will be the same across all threads in a process.) Other fields show the set of pending signals that are directed to the thread (\fISigPnd\fP) as well as the set of pending signals that are directed to the process as a whole (\fIShdPnd\fP). The corresponding fields in \fI/proc/\fPpid\fI/status\fP show the information for the main thread. See \fBproc\fP(5) for further details. .SH ОШИБКИ There are six signals that can be delivered as a consequence of a hardware exception: \fBSIGBUS\fP, \fBSIGEMT\fP, \fBSIGFPE\fP, \fBSIGILL\fP, \fBSIGSEGV\fP, and \fBSIGTRAP\fP. Which of these signals is delivered, for any given hardware exception, is not documented and does not always make sense. .P For example, an invalid memory access that causes delivery of \fBSIGSEGV\fP on one CPU architecture may cause delivery of \fBSIGBUS\fP on another architecture, or vice versa. .P For another example, using the x86 \fIint\fP instruction with a forbidden argument (any number other than 3 or 128) causes delivery of \fBSIGSEGV\fP, even though \fBSIGILL\fP would make more sense, because of how the CPU reports the forbidden operation to the kernel. .SH "СМОТРИТЕ ТАКЖЕ" \fBkill\fP(1), \fBclone\fP(2), \fBgetrlimit\fP(2), \fBkill\fP(2), \fBpidfd_send_signal\fP(2), \fBrestart_syscall\fP(2), \fBrt_sigqueueinfo\fP(2), \fBsetitimer\fP(2), \fBsetrlimit\fP(2), \fBsgetmask\fP(2), \fBsigaction\fP(2), \fBsigaltstack\fP(2), \fBsignal\fP(2), \fBsignalfd\fP(2), \fBsigpending\fP(2), \fBsigprocmask\fP(2), \fBsigreturn\fP(2), \fBsigsuspend\fP(2), \fBsigwaitinfo\fP(2), \fBabort\fP(3), \fBbsd_signal\fP(3), \fBkillpg\fP(3), \fBlongjmp\fP(3), \fBpthread_sigqueue\fP(3), \fBraise\fP(3), \fBsigqueue\fP(3), \fBsigset\fP(3), \fBsigsetops\fP(3), \fBsigvec\fP(3), \fBsigwait\fP(3), \fBstrsignal\fP(3), \fBswapcontext\fP(3), \fBsysv_signal\fP(3), \fBcore\fP(5), \fBproc\fP(5), \fBnptl\fP(7), \fBpthreads\fP(7), \fBsigevent\fP(3type) .PP .SH ПЕРЕВОД Русский перевод этой страницы руководства разработал(и) Alexander Golubev , Azamat Hackimov , Hotellook, Nikita , Spiros Georgaras , Vladislav , Yuri Kozlov и Иван Павлов . .PP Этот перевод является свободной программной документацией; он распространяется на условиях общедоступной лицензии GNU (GNU General Public License - GPL, .UR https://www.gnu.org/licenses/gpl-3.0.html .UE версии 3 или более поздней) в отношении авторского права, но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ. .PP Если вы обнаружите какие-либо ошибки в переводе этой страницы руководства, пожалуйста, сообщите об этом разработчику(ам) по его(их) адресу(ам) электронной почты или по адресу .MT списка рассылки русских переводчиков .ME .