□ исполняемый файл процесса имеет установленный бит SUID, и реальный владелец-пользователь процесса не является владельцем- пользователем исполняемого файла;
□ исполняемый файл процесса имеет установленный бит SGID, и реальный владелец-группа процесса не является владельцем-группой исполняемого файла;
□ процесс не имеет права записи в текущем рабочем каталоге;
□ размер файла core слишком велик (превышает допустимый предел RLIMIT_CORE, см. раздел "Ограничения" далее в этой главе).
Таблица 2.18. Сигналы
| Название | Действие по умолчанию | Значение |
|---|---|---|
| SIGABRT | Завершить+core | Сигнал отправляется, если процесс вызывает системный вызов abort(2). |
| SIGALRM | Завершить | Сигнал отправляется, когда срабатывает таймер, ранее установленный с помощью системных вызовов alarm(2) или setitimer(2). |
| SIGBUS | Завершить+core | Сигнал свидетельствует о некоторой аппаратной ошибке. Обычно этот сигнал отправляется при обращении к допустимому виртуальному адресу, для которого отсутствует соответствующая физическая страница. Другой случай генерации этого сигнала упоминался при обсуждении файлов, отображаемых в память (сигнал отправляется процессу при попытке обращения к странице виртуальной памяти, лежащей за пределами файла). |
| SIGCHLD | Игнорировать | Сигнал, посылаемый родительскому процессу при завершении выполнения его потомка. |
| SIGEGV | Завершить+core | Сигнал свидетельствует о попытке обращения к недопустимому адресу или к области памяти, для которой у процесса недостаточно привилегий. |
| SIGFPE | Завершить+core | Сигнал свидетельствует о возникновении особых ситуаций, таких как деление на 0 или переполнение операции с плавающей точкой. |
| SIGHUP | Завершить | Сигнал посылается лидеру сеанса, связанному с управляющим терминалом, когда ядро обнаруживает, что терминал отсоединился (потеря линии). Сигнал также посылается всем процессам текущей группы при завершении выполнения лидера. Этот сигнал иногда используется в качестве простейшего средства межпроцессного взаимодействия. В частности, он применяется для сообщения демонам о необходимости обновить конфигурационную информацию. Причина выбора именно сигнала SIGHUP заключается в том, что демон по определению не имеет управляющего терминала и, соответственно, обычно не получает этого сигнала. |
| SIGILL | Завершить+core | Сигнал посылается ядром, если процесс попытался выполнить недопустимую инструкцию. |
| SIGINT | Завершить | Сигнал посылается ядром всем процессам текущей группы при нажатии клавиши прерывания (<Del> или <Ctrl>+<C>). |
| SIGKILL | Завершить | Сигнал, при получении которого выполнение процесса завершается. Этот сигнал нельзя ни перехватить, ни игнорировать. |
| SIGPIPE | Завершить | Сигнал посылается при попытке записи в канал или сокет, получатель данных которого завершил выполнение (закрыл соответствующий дескриптор). |
| SIGPOLL | Завершить | Сигнал отправляется при наступлении определенного события для устройства, которое является опрашиваемым. |
| SIGPWR | Игнорировать | Сигнал генерируется при угрозе потери питания. Обычно он отправляется, когда питание системы переключается на источник бесперебойного питания (UPS). |
| SIGQUIT | Завершить+core | Сигнал посылается ядром всем процессам текущей группы при нажатии клавиш <Ctrl>+<\>. |
| SIGSTOP | Остановить | Сигнал отправляется всем процессам текущей группы при нажатии пользователем клавиш <Ctrl>+<Z>. Получение сигнала вызывает останов выполнения процесса. |
| SIGSYS | Завершить+core | Сигнал отправляется ядром при попытке недопустимого системного вызова. |
| SIGTERM | Завершить | Сигнал обычно представляет своего рода предупреждение, что процесс вскоре будет уничтожен. Этот сигнал позволяет процессу соответствующим образом "подготовиться к смерти" - удалить временные файлы, завершить необходимые транзакции и т.д. Команда kill(1) по умолчанию отправляет именно этот сигнал. |
| SIGTTIN | Остановить | Сигнал генерируется ядром (драйвером терминала) при попытке процесса фоновой группы осуществить чтение с управляющего терминала. |
| SIGTTOU | Остановить | Сигнал генерируется ядром (драйвером терминала) при попытке процесса фоновой группы осуществить запись на управляющий терминал. |
| SIGUSR1 | Завершить | Сигнал предназначен для прикладных задач как простейшее средство межпроцессного взаимодействия. |
| SIGUSR2 | Завершить | Сигнал предназначен для прикладных задач как простейшее средство межпроцессного взаимодействия. |
Простейшим интерфейсом к сигналам UNIX является устаревшая, но по-прежнему поддерживаемая в большинстве систем функция signal(3C). Эта функция позволяет изменить диспозицию сигнала, которая по умолчанию устанавливается ядром UNIX. Порожденный вызовом fork(2) процесс наследует диспозицию сигналов от своего родителя. Однако при вызове exec(2) диспозиция всех перехватываемых сигналов будет установлена на действие по умолчанию. Это вполне естественно, поскольку образ новой программы не содержит функции-обработчика, определенной диспозицией сигнала перед вызовом exec(2). Функция signal(3C) имеет следующее определение:
#include <signal.h>
void(*signal(int sig, void (*disp)(int)))(int);
Аргумент sig определяет сигнал, диспозицию которого нужно изменить.
Аргумент disp определяет новую диспозицию сигнала, которой может быть определенная пользователем функция-обработчик или одно из следующих значений:
| SIG_DFL | Указывает ядру, что при получении процессом сигнала необходимо вызвать системный обработчик, т.е. выполнить действие по умолчанию. |
| SIG_IGN | Указывает, что сигнал следует игнорировать. Напомним, что не все сигналы можно игнорировать. |
В случае успешного завершения signal(3C) возвращает предыдущую диспозицию - это может быть функция-обработчик сигнала или системные значения SIG_DFL или SIG_IGN. Возвращаемое значение может быть использовано для восстановления диспозиции в случае необходимости.
Использование функции signal(3C) подразумевает семантику устаревших или ненадежных сигналов. Процесс при этом имеет весьма слабые возможности управления сигналами. Во-первых, процесс не может заблокировать сигнал, т. е. отложить получение сигнала на период выполнения критического участка кода. Во-вторых, каждый раз при получении сигнала, его диспозиция устанавливается на действие по умолчанию. Данная функция и соответствующая ей семантика сохранены для поддержки старых версий приложений. В связи с этим в новых приложениях следует избегать использования функции signal(3C). Тем не менее для простейшей иллюстрации использования сигналов, приведенный ниже пример использует именно этот интерфейс:
#include <signal.h>
/* Функция-обработчик сигнала */
static void sig_hndlr(int signo) {
/* Восстановим диспозицию */
signal(SIGINT, sig_hndlr);
printf("Получен сигнал SIGINT\n");
}
main() {
/* Установим диспозицию */
signal(SIGINT, sih_hndlr);
signal(SIGUSR1, SIG_DFL);
signal(SIGUSR2, SIG_IGN);
/* Бесконечный цикл */
while(1)
pause();
}
В этом примере изменена диспозиция трех сигналов: SIGINT, SIGUSR1 и SIGUSR2. При получении сигнала SIGINT вызывается обработчик при получении сигнала SIGUSR1 производится действие по умолчанию (процесс завершает работу), а сигнал SIGUSR2 игнорируется. После установки диспозиции сигналов процесс запускает бесконечный цикл, в процессе которого вызывается функция pause(2). При получении сигнала, который не игнорируется, pause(2) возвращает значение -1, а переменная errno устанавливается равной EINTR. Заметим, что каждый раз при получении сигнала SIGINT мы вынуждены восстанавливать требуемую диспозицию, в противном случае получение следующего сигнала этого типа вызвало бы завершение выполнения процесса (действие по умолчанию).
При запуске программы, получим следующий результат:
$ а.out &
[1] 8365 PID порожденного процесса
$ kill -SIGINT 8365
Получен сигнал SIGINT Сигнал SIGINT перехвачен
$ kill -SIGUSR2 8365 Сигнал SIGUSR2 игнорируется
$ kill -SIGUSR1 8365
[1]+ User Signal 1 Сигнал SIGUSR1 вызывает завер-
a.out шение выполнения процесса
$
Для отправления сигналов процессу использована команда kill(1), описанная в предыдущей главе.
Надежные сигналы
Стандарт POSIX. 1 определил новый набор функций управления сигналами. основанный на интерфейсе 4.2BSD UNIX и лишенный рассмотренных выше недостатков.
Модель сигналов, предложенная POSIX, основана на понятии набора сигналов (signal set), описываемого переменной типа sigset_t. Каждый бит этой переменной отвечает за один сигнал. Во многих системах тип sigset_t имеет длину 32 бита, ограничивая количество возможных сигналов числом 32.
Следующие функции позволяют управлять наборами сигналов:
#include <signal.h>
int sigempyset(sigset_t *set);
int siufillset(sigset_t *set);
int sigaddset(sigset_t *set, int signo);
int sigdelset(sigset_t *set, int signo);
int sigismember(sigset_t *set, int signo);
В отличие от функции signal(3C), изменяющей диспозицию сигналов, данные функции позволяют модифицировать структуру данных sigset_t, определенную процессом. Для управления непосредственно сигналами используются дополнительные функции, которые мы рассмотрим позже.
Функция sigemptyset(3C) инициализирует набор, очищая все биты. Если процесс вызывает sigfillset(3C), то набор будет включать все сигналы, известные системе. Функции sigaddset(3C) и sigdelset(3C) позволяют добавлять или удалять сигналы набора. Функция sigismember(3C) позволяет проверить, входит ли указанный параметром signo сигнал в набор.
Вместо функции signal(3C) стандарт POSIX. 1 определяет функцию sigaction(2), позволяющую установить диспозицию сигналов, узнать ее текущее значение или сделать и то и другое одновременно. Функция имеет следующее определение:
#include <signal.h>
int sigaction (int sig, const struct sigaction *act,
struct sigaction *oact);
Вся необходимая для управлением сигналами информация передается через указатель на структуру sigaction, имеющую следующие поля:
| void (*sa_handler)() | Обработчик сигнала sig |
| void (*sa_sigaction)(int, siginfo_t*, void*) | Обработчик сигнала sig при установленном флаге SA_SIGINFO |
| sigset_t sa_mask | Маска сигналов |
| int sa_flags | Флаги |
Поле sa_handler определяет действие, которое необходимо предпринять при получении сигналов, и может принимать значения SIG_IGN, SIG_DFL или адреса функции-обработчика. Если значение sa_handler или sa_sigaction не равны NULL, то в поле sa_mask передается набор сигналов, которые будут добавлены к маске сигналов перед вызовом обработчика. Каждый процесс имеет установленную маску сигналов, определяющую сигналы, доставка которых должна быть заблокирована. Если определенный бит маски установлен, соответствующий ему сигнал будет заблокирован. После возврата из функции-обработчика значение маски возвращается к исходному значению. Заметим, что сигнал, для которого установлена функция-обработчик, также будет заблокирован перед ее вызовом. Такой подход гарантирует, что во время обработки, последующее поступление определенных сигналов будет приостановлено до завершения функции. Как правило, UNIX не поддерживает очередей сигналов, и это значит, что блокировка нескольких однотипных сигналов в конечном итоге вызовет доставку лишь одного.
Поле sa_flags определяет флаги, модифицирующие доставку сигнала. Оно может принимать следующие значения:
| SA_ONSTACK | Если определена функция-обработчик сигнала, и с помощью функции sigaltstack(2) задан альтернативный стек для функции-обработчика, то при обработке сигнала будет использоваться этот стек. Если флаг не установлен, будет использоваться обычный стек процесса. |
| SA_RESETHAND | Если определена функция-обработчик, то диспозиция сигнала будет изменена на SIG_DFL, и сигнал не будет блокироваться при запуске обработчика. Если флаг не установлен, диспозиция сигнала остается неизменной. |
| SA_NODEFER | Если определена функция-обработчик, то сигнал блокируется на время обработки только в том случае, если он явно указан в поле sa_mask. Если флаг не установлен, в процессе обработки данный сигнал автоматически блокируется. |
| SA_RESTART | Если определена функция-обработчик, ряд системных вызовов, выполнение которых было прервано полученным сигналом, будут автоматически перезапущены после обработки сигнала. Если флаг не установлен, системный вызов возвратит ошибку EINTR. |
| SA_SIGINFO | Если диспозиция указывает на перехват сигнала, вызывается функция, адресованная полем sa_sigaction. Если флаг не установлен, вызывается обработчик sa_handler. |
| SA_NOCLDWAIT | Если указанный аргументом sig сигнал равен SIGCHLD, при завершении потомки не будут переходить в состояние зомби. Если процесс в дальнейшем вызовет функции wait(2), wait3(2), waitid(2) или waitpid(2), их выполнение будет блокировано до завершения работы всех потомков данного процесса. |
| SA_NOCLDSTOP | Если указанный аргументом sig сигнал равен SIGCHLD, указанный сигнал не будет отправляться процессу при завершении или останове любого из его потомков. |
Данные флаги не определены для UNIX BSD.
В системах UNIX BSD 4.x структура sigaction имеет следующий вид:
struct sigaction {
void (*sa_handler)();
sigset_t sa_mask;
int sa_flags;
};
где функция-обработчик определена следующим образом:
void handler(int signo, int code, struct sigcontext *scp);
В первом аргументе signo содержится номер сигнала, code определяет дополнительную информацию о причине поступления сигнала, a scp указывает на контекст процесса.