/* При нормальном запуске программы эта часть кода
выполняться уже не будет — можно смело выводить
сообщение об ошибке */
pexit(cmd);
} else
/* Родительский процесс (shell) ожидает завершения
выполнения потомка */
wait(&status);
...
Сигнал является способом передачи уведомления о некотором произошедшем событии между процессами или между ядром системы и процессами. Сигналы можно рассматривать, как простейшую форму межпроцессного взаимодействия, хотя на самом деле они больше напоминают программные прерывания, при которых нарушается нормальное выполнение процесса.
Сигналы появились уже в ранних версиях UNIX, но их реализация не была достаточно надежной. Сигнал мог быть "потерян", возникали также определенные сложности с отключением (блокированием) сигналов на время выполнения критических участков кода. В последующие версии системы, как BSD, так и System V, были внесены изменения, позволившие реализовать надежные (reliable) сигналы . Однако модель сигналов, принятая в версиях BSD, была несовместима с моделью версий System V. В настоящее время стандарт POSIX.1 вносит определенность в интерфейс надежных сигналов.
Прежде всего, каждый сигнал имеет уникальное символьное имя и соответствующий ему номер. Например, сигнал прерывания, посылаемый процессу при нажатии пользователем клавиши < Del > или < Ctrl >+< C >, имеет имя SIGINT
. Сигнал, генерируемый комбинацией < Ctrl >+< \ >, называется SIGQUIT
. Седьмая редакция UNIX насчитывала 15 различных сигналов, а в современных версиях их число увеличилось вдвое.
Сигнал может быть отправлен процессу либо ядром, либо другим процессом с помощью системного вызова kill(2) :
#include
#include
int kill(pid_t pid, int sig);
Аргумент pid
адресует процесс, которому посылается сигнал. Аргумент sig
определяет тип отправляемого сигнала.
К генерации сигнала могут привести различные ситуации:
□ Ядро отправляет процессу (или группе процессов) сигнал при нажатии пользователем определенных клавиш или их комбинаций. Например, нажатие клавиши < Del > (или < Ctrl >+< C >) приведет к отправке сигнала SIGINT
, что используется для завершения процессов, вышедших из-под контроля. [24] Сигналы этого рода генерируются драйвером терминала. Настройка терминального драйвера позволяет связать условие генерации сигнала с любой клавишей.
□ Аппаратные особые ситуации , например, деление на 0, обращение к недопустимой области памяти и т.д., также вызывают генерацию сигнала. Обычно эти ситуации определяются аппаратурой компьютера, и ядру посылается соответствующее уведомление (например, в виде прерывания). Ядро реагирует на это отправкой соответствующего сигнала процессу, который находился в стадии выполнения, когда произошла особая ситуация.
□ Определенные программные состояния системы или ее компонентов также могут вызвать отправку сигнала. В отличие от предыдущего случая, эти условия не связаны с аппаратной частью, а имеют чисто программный характер. В качестве примера можно привести сигнал SIGALRM
, отправляемый процессу, когда срабатывает таймер, ранее установленный с помощью вызова alarm(2) .
С помощью системного вызова kill(2) процесс может послать сигнал как самому себе, так и другому процессу или группе процессов. В этом случае процесс, посылающий сигнал, должен иметь те же реальный и эффективный идентификаторы, что и процесс, которому сигнал отправляется. Разумеется, данное ограничение не распространяется на процессы, обладающие привилегиями суперпользователя. Такие процессы имеют возможность отправлять сигналы любым процессам системы.
Как уже говорилось в предыдущей главе, процесс может выбрать одно из трех возможных действий при получении сигнала:
□ игнорировать сигнал,
□ перехватить и самостоятельно обработать
□ позволить действие по умолчанию.
Текущее действие при получении сигнала называется диспозицией сигнала .
Напомним, что сигналы SIGKILL
и SIGSTOP
невозможно ни игнорировать, ни перехватить. Сигнал SIGKILL
является силовым методом завершения выполнения "непослушного" процесса, а от работоспособности SIGSTOP
зависит функционирование системы управления заданиями.
Условия генерации сигнала и действие системы по умолчанию приведены в табл. 2.18. Как видно из таблицы, при получении сигнала в большинстве случаев по умолчанию происходит завершение выполнения процесса. В ряде случаев в текущем рабочем каталоге процесса также создается файл core(в таблице такие случаи отмечены как "Завершить+core"), в котором хранится образ памяти процесса. Этот файл может быть впоследствии проанализирован программой-отладчиком для определения состояния процесса непосредственно перед завершением. Файл coreне будет создан в следующих случаях:
Читать дальше