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:
$ <b>kill -l</b>
 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
Сигналы 
SIGRT<i>XXX</i>
 являются сигналами реального времени, сложная тема, которую мы не будем рассматривать.
  
10.3.2. Программная отправка сигналов: 
raise()
 
Помимо внешнего генерирования, сигнал может быть отправлен непосредственно самой программой с использованием стандартной функции С 
raise()
:
#include &lt;signal.h&gt; /* 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 &lt;signal.h&gt;
4  #include &lt;string.h&gt;
5  #include &lt;unistd.h&gt;
6
7  /* handler --- простой обработчик сигнала. */
8
9  void handler(int signum)