Андрей Робачевский - Операционная система UNIX
Системный вызов waitid(2) предоставляет больше возможностей для контроля дочернего процесса. Аргументы idtype и id определяют, за какими из дочерних процессов требуется следить:
Значение аргумента idtype Описание P_PID waitid(2) блокирует выполнение процесса, следя за потомком, PID которого равен id. P_PGID waitid(2) блокирует выполнение процесса, следя за потомками, идентификаторы группы которых равны id. P_ALL waitid(2) блокирует выполнение процесса, следя за всеми непосредственными потомками.Аргумент options содержит флаги, объединенные логическим ИЛИ, определяющие, за какими изменениями в состоянии потомков следит waitid(2):
Флаги аргумента options Описание WEXITED Предписывает ожидать завершения выполнения процесса. WTRAPPED Предписывает ожидать ловушки (trap) или точки останова (breakpoint) для трассируемых процессов. WSTOPPED Предписывает ожидать останова процесса из-за получения сигнала. WCONTINUED Предписывает вернуть статус процесса, выполнение которого было продолжено после останова. WNOHANG Предписывает завершить свое выполнение, если отсутствует статусная информация (т.е. отсутствует ожидаемое событие). WNOWAIT Предписывает получить статусную информацию, но не уничтожать ее, оставив дочерний процесс в состоянии ожидания.Аргумент infop указывает на структуру siginfo_t, которая будет заполнена информацией о потомке. Мы рассмотрим эту структуру в следующем разделе.
Функция waitpid(2), как и функции wait(2) и waitid(2), позволяет контролировать определенное множество дочерних процессов.
В заключение для иллюстрации описанных в этом разделе системных вызовов приведем схему работы командного интерпретатора при запуске команды.
...
/* Вывести приглашение shell*/
write(1, "$ ", 2);
/* Считать пользовательский ввод */
get_input(inputbuf);
/* Произвести разбор ввода: выделить команду cmd
и ее аргументы arg[] */
parse_input(inputbuf, and, arg);
/* Породить процесс */
pid = fork();
if (pid == 0) {
/* Запустить программу */
execvp(cmd, arg);
/* При нормальном запуске программы эта часть кода
выполняться уже не будет — можно смело выводить
сообщение об ошибке */
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 <sys/types.h>
#include <signal.h>
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 не будет создан в следующих случаях:
□ исполняемый файл процесса имеет установленный бит 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) имеет следующее определение:
