Linux программирование в примерах

Роббинс Арнольд

Обозначения: Core: Завершить процесс и создать снимок образа процесса Ignr: Игнорировать сигнал Stop: Остановить процесс. Term: Завершить процесс.

Более старые версии оболочки Борна (

/bin/sh

) непосредственно связывали с номерами сигналов ловушки (traps), которые являются обработчиками сигналов на уровне оболочки. Таким образом, всесторонне образованному Unix-программисту нужно было знать не только имена сигналов для использования в коде С, но также и соответствующие номера сигналов! POSIX требует, чтобы команда

trap

понимала символические имена сигналов (без префикса '

SIG

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

ЗАМЕЧАНИЕ. Для некоторых более новых сигналов, от 16 и выше, соответствующие номера сигнала и их имена на различных платформах не обязательно совпадают! Проверьте заголовочные файлы и справочные страницы на своей системе. Табл. 10.1 верна для GNU/Linux

Некоторые системы определяют также и другие сигналы, такие, как

SIGEMT

,

SIGLOST

и

SIGINFO

. Справочная страница GNU/Linux signal(7) предоставляет полный список; если ваша программа должна обработать сигналы, не поддерживаемые GNU/Linux, это можно сделать с помощью

#ifdef

:

#ifdef SIGLOST

/* ...обработать здесь SIGLOST... */

#endif

За исключением

SIGSTKFLT

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

#ifdef

.

Сигналы

SIGKILL

и

SIGSTOP

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

Чтобы увидеть список поддерживаемых сигналов, вы можете использовать '

kill -l

'. На одной из наших систем GNU/Linux:

$ kill -l

 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL

 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE

 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2

13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD

18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN

22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ

26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO

30) SIGPWR 31) SIGSYS 32) SIGRTMIN 33) SIGRTMIN+1

34) SIGRTMIN+2 35) SIGRTMIN+3 36) SIGRTMIN+4 37) SIGRTMIN+5

38) SIGRTMIN+6 39) SIGRTMIN+7 40) SIGRTMIN+8 41) SIGRTMIN+9

42) SIGRTMIN+10 43) SIGRTMIN+11 44) SIGRTMIN+12 45) SIGRTMIN+13

46) SIGRTMIN+14 47) SIGRTMIN+15 48) SIGRTMAX-15 49) SIGRTMAX-14

50) SIGRTMAX-13 51) SIGRTMAX-12 52) SIGRTMAX-11 53) SIGRTMAX-10

54) SIGRTMAX-9 55) SIGRTMAX-8 56) SIGRTMAX-7 57) SIGRTMAX-6

58) SIGRTMAX-5 59) SIGRTMAX-4 60) SIGRTMAX-3 61) SIGRTMAX-2

62) SIGRTMAX-1 63) SIGRTMAX

Сигналы

SIGRTXXX

являются сигналами реального времени, сложная тема, которую мы не будем рассматривать.

10.3.2. Программная отправка сигналов:

raise

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

raise

:

#include <signal.h> /* ISO С */

int raise(int sig);

Эта функция посылает сигнал

sig

вызывающему процессу. (Это действие имеет свое применение; вскоре мы увидим пример.)

Поскольку

raise

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

10.4. Обработчики сигналов в действии

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

10.4.1. Традиционные системы

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

raise

).

По получении сигнала ядро останавливает процесс, где бы он ни был. Затем оно имитирует вызов процедуры обработчика сигнала, передавая ему номер сигнала в качестве ее единственного аргумента. Ядро устраивает все таким образом, что нормальный возврат из функции обработчика сигнала (либо посредством

return

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

Что происходит после обработки сигнала, когда тот же самый сигнал появится в следующий раз снова? Остается ли обработчик на том же месте? Или же он сбрасывается, и для сигнала используется действие по умолчанию? Ответ, по историческим причинам, «зависит от». В частности, стандарт С оставляет это на усмотрение реализации.

На практике V7 и традиционные системы System V, такие, как Solaris, устанавливают для сигнала действие по умолчанию.

Давайте рассмотрим простой обработчик сигнала в действии под Solaris. Следующая программа,

ch10-catchint.c

, перехватывает

SIGINT

. Обычно вы генерируете этот сигнал, набирая на клавиатуре CTRL-C.

1 /* ch10-catchint.c - перехват SIGINT, по крайней мере, однажды. */

2

3 #include <signal.h>

4 #include <string.h>

5 #include <unistd.h>

6

7 /* handler --- простой обработчик сигнала. */

8

9 void handler(int signum)

10 {

11 char buf[200], *cp;

12 int offset;