Scroll to navigation

SIGNAL(7) Руководство программиста Linux SIGNAL(7)

ИМЯ

signal - обзор сигналов

ОПИСАНИЕ

В Linux поддерживаются надёжные (reliable) сигналы POSIX (далее, «стандартные сигналы») и сигналы реального времени POSIX.

Обработчики сигнала

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

В таблицах далее есть столбец «Действие», в котором указан обработчик по умолчанию для каждого сигнала:

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

Процесс может изменить обработчик сигнала с помощью sigaction(2) или signal(2) (менее переносим; дополнительную информацию смотрите в signal(2)). Используя данные системные вызовы процесс может выбрать одно из следующих действий при получении сигнала: выполнить действие по умолчанию, игнорировать сигнал, поймать сигнал обработчиком сигнала — функцией, задаваемой программистом, которая автоматически вызывается при получении сигнала (по умолчанию обработчик сигнала использует обычный стек процесса. Возможно сделать так, чтобы обработчик сигнала использовал альтернативный стек; как это делается и когда это может быть полезно смотрите в sigaltstack(2)).

Реакция на сигналы является атрибутом процесса: в многонитиевом приложении реакция на определённый сигнал одинакова для всех нитей.

Потомок, созданный с помощью fork(2), наследует реакцию на сигналы от своего родителя. При execve(2) реакция на сигналы устанавливается в значение по умолчанию; реакция на игнорируемые сигналы не изменяется.

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

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

raise(3)
Посылает сигнал вызвавшей нити.
kill(2)
Посылает сигнал указанному процессу, всем членам указанной группы процессов или всем процессам в системе.
killpg(2)
Посылает сигнал всем членам указанной группы процессов.
pthread_kill(3)
Посылает сигнал указанной нити POSIX в том же процессе, что и вызывающий.
tgkill(2)
Посылает сигнал указанной нити в указанном процессе (данный системный вызов используется в реализации pthread_kill(3)).
sigqueue(3)
Посылает сигнал реального времени указанному процессу с сопроводительными данными.

Ожидание сигнала для обработки

Следующие системные вызовы приостанавливают выполнение вызывающего процесса или нити до тех пор, пока не будет пойман сигнал (или необработанный сигнал не завершит процесс):

pause(2)
Приостанавливает выполнение до тех пор, пока не будет пойман любой сигнал.
sigsuspend(2)
Временно изменяет маску сигналов (смотрите далее) и приостанавливает выполнение до получения одного из незамаскированных сигналов.

Синхронный приём сигнала

В отличие от асинхронного получения сигнала через обработчик, возможно синхронно получить сигнал, то есть блокировать выполнение до поступления сигнала в некоторой точке, в которой ядро вернёт информацию о сигнале вызывающему. Для этого существует два пути:

  • С помощью sigwaitinfo(2), sigtimedwait(2) и sigwait(3). Они приостанавливают выполнение до поступления одного из заданного набора сигналов. Каждый из этих вызовов возвращает информацию о полученном сигнале.
  • С помощью signalfd(2). Данный вызов возвращает файловый дескриптор, который можно использовать для чтения информации о сигналах, доставляемых вызывающему. Каждое выполнение read(2) с этим файловым дескриптором блокируется до тех пор, пока один из сигналов набора, указанного в вызове signalfd(2), не будет послан вызывающему. В возвращаемом read(2) буфере содержится структура, описывающая сигнал.

Сигнальная маска и ожидающие сигналы

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

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

Потомок, создаваемый с помощью fork(2), наследует копию родительской маски сигналов; маска сигналов сохраняется при вызове execve(2).

Сигнал может быть сгенерирован (а значит и стать ожидающим) как для всего процесса (например, при отправке с помощью kill(2)) так и для отдельной нити (например, некоторые сигналы, такие как SIGSEGV и SIGFPE, сгенерированные в следствии выполнения определённой инструкции на машинном языке в самой нити, или сигналы, направленные определённой нити с помощью pthread_kill(3)). Направленный процессу сигнал может быть доставлен в любую из нитей, у которых сигнал не заблокирован. Если имеется несколько таких нитей, то ядро выбирает произвольную нить, которой и доставит сигнал.

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

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

Стандартные сигналы

Linux поддерживает стандартные сигналы, перечисленные далее. Номера некоторых сигналов зависят от используемой архитектуры, это указано в столбце «Номер» (если указано три значения, то первое, обычно, применяется в alpha и sparc, второе — в x86, arm и в большинстве других архитектур, и третье — в mips. Номера для parisc не показаны; номера для этой архитектуры смотрите в исходном коде ядра. Символ A означает, что сигнал отсутствует в соответствующей архитектуре).

Сначала рассмотрим сигналы, описанные в стандарте POSIX.1-1990.

Сигнал Номер Действие Комментарий
SIGHUP  1 Term Обнаружен обрыв связи с управляющим
терминалом, либо завершение управляющего
терминалом процесса
SIGINT  2 Term Прерывание с клавиатуры
SIGQUIT  3 Core Выход с клавиатуры
SIGILL  4 Core Несуществующая инструкция
SIGABRT  6 Core Сигнал аварии (abort), посланный
abort(3)
SIGFPE  8 Core Ошибка операций с плавающей запятой
SIGKILL  9 Term Kill-сигнал
SIGSEGV 11 Core Некорректная ссылка в память
SIGPIPE 13 Term Оборванный канал: запись в канал,
из которого не читают
SIGALRM 14 Term Сигнал таймера, посланный alarm(2)
SIGTERM 15 Term Сигнал завершения
SIGUSR1 30,10,16 Term Первый сигнал, определяемый
пользователем
SIGUSR2 31,12,17 Term Второй сигнал, определяемый
пользователем
SIGCHLD 20,17,18 Ign Потомок остановлен или прекратил
выполнение
SIGCONT 19,18,25 Cont Продолжить выполнение, если остановлен
SIGSTOP 17,19,23 Stop Остановить выполнение процесса
SIGTSTP 18,20,24 Stop Останов введён с терминала
SIGTTIN 21,21,26 Stop Ввод с терминала у фонового процесса
SIGTTOU 22,22,27 Stop Вывод на терминал у фонового процесса

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

Далее приведены сигналы, не входящие в POSIX.1-1990, но описанные в SUSv2 и POSIX.1-2001.

Сигнал Номер Действие Комментарий
SIGBUS 10,7,10 Core Ошибка шины (некорректный адрес
доступа)
SIGPOLL Term Событие опроса (Sys V).
Синоним SIGIO
SIGPROF 27,27,29 Term Закончилось время профилирующего
таймера
SIGSYS 12,31,12 Core Недопустимый аргумент для процедуры
(SVr4)
SIGTRAP 5 Core Ловушка трассировки/отладки
SIGURG 16,23,21 Ign Приоритетное состояние у сокета
(4.2BSD)
SIGVTALRM 26,26,28 Term Виртуальный таймер (4.2BSD)
SIGXCPU 24,24,30 Core Превышено время работы на ЦП (4.2BSD)
SIGXFSZ 25,25,31 Core Превышен размер файла (4.2BSD)

В Linux до версии 2.2 включительно поведением по умолчанию для сигналов SIGSYS, SIGXCPU, SIGXFSZ и SIGBUS (на всех архитектурах кроме SPARC и MIPS) было завершение процесса без создания дампа (в некоторых системах UNIX действием по умолчанию для SIGXCPU и SIGXFSZ является завершение процесса без создания дампа). Linux версии 2.4 соответствует требованиям POSIX.1-2001 для этих сигналов и завершает процесс с созданием дампа.

Некоторые другие сигналы.

Сигнал Номер Действие Комментарий
SIGIOT 6 Core Ловушка IOT. Синоним SIGABRT
SIGEMT 7,-,7 Term
SIGSTKFLT -,16,- Term Ошибка стека на сопроцессоре
(не используется)
SIGIO 23,29,22 Term Теперь возможен ввод/вывод (4.2BSD)
SIGCLD -,-,18 Ign Синоним SIGCHLD
SIGPWR 29,30,19 Term Отказ системы питания (System V)
SIGINFO 29,-,- Синоним SIGPWR
SIGLOST -,-,- Term Утрачена блокировка файла (не используется)
SIGWINCH 28,28,20 Ign Сигнал изменения размера окна
(4.3BSD, Sun)
SIGUNUSED -,31,- Core Синоним SIGSYS

Сигнал с номером 29 на alpha соответствует SIGINFO / SIGPWR, а на sparc соответствует SIGLOST.

Сигнал SIGEMT не определён в POSIX.1-2001, но, тем не менее, появляется почти во всех системах UNIX, где действием по умолчанию для него является завершение процесса с созданием дампа.

Сигнал SIGPWR (не определён в POSIX.1-2001) по умолчанию, обычно, игнорируется (в других системах UNIX).

Для сигнала SIGIO (не определён в POSIX.1-2001) в других системах UNIX действием по умолчанию является игнорирование.

Если определён сигнал SIGUNUSED, то он является синонимом SIGSYS для большинства архитектур.

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

Linux поддерживает сигналы реального времени согласно первоначальному описанию расширений реального времени в POSIX.1b (теперь включено в POSIX.1-2001). Диапазон поддерживаемых сигналов реального времени определяется макросами SIGRTMIN и SIGRTMAX. Согласно POSIX.1-2001 требуется, чтобы реализация поддерживала не менее _POSIX_RTSIG_MAX (8) сигналов реального времени.

Ядро Linux поддерживает 32 таких сигнала, начиная с номера 32 до номера 63. Однако внутри реализации нитей POSIX в glibc используется два (для NPTL) или три (для LinuxThreads) сигнала реального времени (смотрите pthreads(7)), а значение SIGRTMIN корректируется должным образом (до 34 или 35). Так как диапазон доступных сигналов реального времени различается в зависимости от реализации нитей в glibc (и это может происходить во время выполнения при смене ядра и glibc), и, более того, диапазон сигналов реального времени различен в разных системах UNIX, то программы никогда не должны задавать сигналы реального времени по номерам, а вместо этого всегда должны записывать их в виде SIGRTMIN+n и выполнять проверку (во время выполнения), что SIGRTMIN+n не превышает SIGRTMAX.

В отличие от стандартных сигналов, сигналы реального времени не имеют предопределенного назначения: весь набор сигналов реального времени приложения могут использовать так, как им нужно.

Действием по умолчанию для необработанных сигналов реального времени является завершение процесса (terminate).

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

1.
В очередь можно добавлять несколько экземпляров одного сигнала реального времени. В случае со стандартными сигналами, если доставляется несколько экземпляров сигнала, в то время как этот тип сигнала в данный момент заблокирован, то только один экземпляр будет добавлен в очередь.
2.
Если сигнал отправляется с помощью sigqueue(3), то с сигналом может быть отправлено некоторое значение (целочисленное, либо указатель). Если принимающий процесс устанавливает обработчик для сигнала, используя флаг SA_SIGINFO и вызов sigaction(2), то он может получить это значение через поле si_value структуры siginfo_t, переданной обработчику в виде второго аргумента. Кроме этого, поля si_pid и si_uid данной структуры можно использовать для получения идентификатора процесса и реального идентификатора пользователя, отправившего сигнал.
3.
Сигналы реального времени доставляются точно в порядке поступления. Несколько сигналов одного типа доставляются в порядке, определяемых их отправлением. Если процессу отправлено несколько разных сигналов реального времени, то порядок их доставки начинается с сигнала с наименьшим номером (то есть сигналы с наименьшим номером имеют наивысший приоритет). Порядок же для стандартных сигналов в такой ситуации не определён.

Если процессу передан и стандартный сигнал, и сигнал реального времени, то в POSIX однозначно не определено, какой из них будет доставлен первым. В Linux, как и во многих других реализациях в таких случаях, отдан приоритет стандартным сигналам.

В соответствии с POSIX, реализация должна позволять ставить в очередь процесса как минимум _POSIX_SIGQUEUE_MAX (32) сигнала. Однако в Linux это делается по-другому. В ядрах до версии 2.6.7 включительно, Linux накладывает общесистемный лимит на количество сигналов режима реального времени в очереди для всех процессов. Этот лимит может быть получен и изменён (если есть права) через файл /proc/sys/kernel/rtsig-max. Текущее количество сигналов режима реального времени в очереди можно получить из файла /proc/sys/kernel/rtsig-nr. В Linux 2.6.8 данные интерфейсы /proc были заменены на ограничение ресурса RLIMIT_SIGPENDING, которое устанавливает ограничение на очередь сигналов на каждого пользователя отдельно; дополнительную информацию можно найти в setrlimit(2).

Безопасные асинхронные функции при работе с сигналами

Функция обработки сигнала должна быть написана очень аккуратно, так как она может быть вызвана в любом месте работы программы. В POSIX есть понятие «безопасной функции». Если сигнал прерывает выполнение небезопасной функции или обработчик вызывает небезопасную функцию, то поведение программы не определено.

Согласно POSIX.1-2004 (также называемом POSIX.1-2001 Technical Corrigendum 2) от реализации требуется гарантировать, что следующие функции можно безопасно вызывать из обработчика сигнала:


_Exit()
_exit()
abort()
accept()
access()
aio_error()
aio_return()
aio_suspend()
alarm()
bind()
cfgetispeed()
cfgetospeed()
cfsetispeed()
cfsetospeed()
chdir()
chmod()
chown()
clock_gettime()
close()
connect()
creat()
dup()
dup2()
execle()
execve()
fchmod()
fchown()
fcntl()
fdatasync()
fork()
fpathconf()
fstat()
fsync()
ftruncate()
getegid()
geteuid()
getgid()
getgroups()
getpeername()
getpgrp()
getpid()
getppid()
getsockname()
getsockopt()
getuid()
kill()
link()
listen()
lseek()
lstat()
mkdir()
mkfifo()
open()
pathconf()
pause()
pipe()
poll()
posix_trace_event()
pselect()
raise()
read()
readlink()
recv()
recvfrom()
recvmsg()
rename()
rmdir()
select()
sem_post()
send()
sendmsg()
sendto()
setgid()
setpgid()
setsid()
setsockopt()
setuid()
shutdown()
sigaction()
sigaddset()
sigdelset()
sigemptyset()
sigfillset()
sigismember()
signal()
sigpause()
sigpending()
sigprocmask()
sigqueue()
sigset()
sigsuspend()
sleep()
sockatmark()
socket()
socketpair()
stat()
symlink()
sysconf()
tcdrain()
tcflow()
tcflush()
tcgetattr()
tcgetpgrp()
tcsendbreak()
tcsetattr()
tcsetpgrp()
time()
timer_getoverrun()
timer_gettime()
timer_settime()
times()
umask()
uname()
unlink()
utime()
wait()
waitpid()
write()

В POSIX.1-2008 из списка выше удалены функции fpathconf(), pathconf() и sysconf() и добавлены следующие:


execl()
execv()
faccessat()
fchmodat()
fchownat()
fexecve()
fstatat()
futimens()
linkat()
mkdirat()
mkfifoat()
mknod()
mknodat()
openat()
readlinkat()
renameat()
symlinkat()
unlinkat()
utimensat()
utimes()

Прерывание системных вызовов и библиотечных функций обработчиками сигналов

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

  • вызов автоматически перезапускается после возврата из обработчика сигнала; или
  • вызов завершается с ошибкой EINTR.

Выбираемое поведение зависит от интерфейса и от того, был ли обработчик сигнала установлен с флагом SA_RESTART (смотрите sigaction(2)). Но в различных системах UNIX есть другие различия; далее описаны подробности для Linux.

Если заблокированный вызов к одному из следующих интерфейсов прерван обработчиком сигнала, то вызов будет автоматически перезапущен после завершения обработчика сигнала, если задействован флаг SA_RESTART; иначе вызов завершается с ошибкой EINTR:

  • Вызовы read(2), readv(2), write(2), writev(2) и ioctl(2) для «медленных» устройств. Устройство считается «медленным», если его ввод-вывод может выполнять блокировку на неопределённое время; к таким устройствам относятся терминалы, каналы или сокеты (диск не является медленным устройством согласно этому определению). Если вызов ввода-вывода на медленном устройстве уже передал какие-то данные до того как был прерван обработчиком сигнала, то вызов завершится без ошибки (обычно, при этом возвращается количество переданных байт).
  • Вызов open(2), если он может выполнить блокировку (например, при открытии FIFO; смотрите fifo(7)).
  • Вызовы wait(2), wait3(2), wait4(2), waitid(2) и waitpid(2).
  • Интерфейсы сокетов: accept(2), connect(2), recv(2), recvfrom(2), recvmsg(2), send(2), sendto(2) и sendmsg(2), если для сокета не указано время ожидания (смотрите далее).
  • Интерфейсы файловой блокировки: flock(2) и fcntl(2) с F_SETLKW.
  • Интерфейсы очереди сообщений POSIX: mq_receive(3), mq_timedreceive(3), mq_send(3) и mq_timedsend(3).
  • Вызов futex(2) с FUTEX_WAIT (начиная с Linux 2.6.22; до этой версии вызов завершался с ошибкой EINTR).
  • Интерфейсы семафоров POSIX: sem_wait(3) и sem_timedwait(3) (начиная с Linux 2.6.22; до этой версии вызовы завершались с ошибкой EINTR).

Следующие интерфейсы никогда не перезапускаются после прерывания обработчиком сигнала независимо от наличия SA_RESTART; они всегда завершаются с ошибкой EINTR, если прерываются обработчиком сигнала:

Функция sleep(3) также никогда не перезапускается, если прервана обработчиком сигнала, но сообщает об успешном выполнении: возвращает количество оставшиеся для сна секунд.

Прерывание системных вызовов и библиотечных функций сигналами останова

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

Интерфейсы Linux, к которым это относится:

СООТВЕТСТВИЕ СТАНДАРТАМ

POSIX.1, кроме описанных исключений.

СМОТРИТЕ ТАКЖЕ

kill(1), getrlimit(2), kill(2), killpg(2), rt_sigqueueinfo(2), setitimer(2), setrlimit(2), sgetmask(2), sigaction(2), sigaltstack(2), signal(2), signalfd(2), sigpending(2), sigprocmask(2), sigsuspend(2), sigwaitinfo(2), abort(3), bsd_signal(3), longjmp(3), raise(3), pthread_sigqueue(3), sigqueue(3), sigset(3), sigsetops(3), sigvec(3), sigwait(3), strsignal(3), sysv_signal(3), core(5), proc(5), pthreads(7), sigevent(7)

2012-05-01 Linux