Почему многие программы Unix используют сигналы, подобные USR1? Системные вызовы wait() и waitpid(). Сигналы в ОС Unix
Рассмотрим теперь другую программу – 13–14-3.c :
/* Программа с пользовательской обработкой
сигнала SIGINT */
#include
Эта программа
отличается от программы из раздела "Прогон программы, игнорирующей сигнал SIGINT
" тем, что в ней введена обработка сигнала SIGINT
пользовательской функцией. Наберите, откомпилируйте и запустите эту программу, проверьте ее реакцию на нажатие клавиш < CTRL
> и
Модификация предыдущей программы для пользовательской обработки сигналов SIGINT и SIGQUIT
Модифицируйте программу из предыдущего раздела так, чтобы она печатала сообщение и о нажатии клавиш < CTRL > и <4>. Используйте одну и ту же функцию для обработки сигналов SIGINT и SIGQUIT . Откомпилируйте и запустите ее, проверьте корректность работы. Снимать программу также придется с другого терминала командой kill .
Восстановление предыдущей реакции на сигнал
До сих пор в примерах мы игнорировали значение , возвращаемое системным вызовом signal() . На самом деле этот системный вызов возвращает указатель на предыдущий обработчик сигнала , что позволяет восстанавливать переопределенную реакцию на сигнал . Рассмотрим пример программы 13-14-4.c , возвращающей первоначальную реакцию на сигнал SIGINT после 5 пользовательских обработок сигнала .
/* Программа с пользовательской обработкой
сигнала SIGINT, возвращающаяся к первоначальной
реакции на этот сигнал после 5 его обработок*/
#include
Наберите, откомпилируйте программу и запустите ее на исполнение .
Сигналы SIGUSR1 и SIGUSR2. Использование сигналов для синхронизации процессов
В операционной системе UNIX существует два сигнала , источниками которых могут служить только системный вызов kill() или команда kill , – это сигналы SIGUSR1 и SIGUSR2 . Обычно их применяют для передачи информации о происшедшем событии от одного пользовательского процесса другому в качестве сигнального средства связи .
В материалах семинара 5 (раздел "Написание, компиляция и запуск программы для организации двунаправленной связи между родственными процессами через pipe "), когда рассматривалась связь родственных процессов через pipe , речь шла о том, что pipe является однонаправленным каналом связи, и что для организации связи через один pipe в двух направлениях необходимо задействовать механизмы взаимной синхронизации процессов. Организуйте двустороннюю поочередную связь процесса-родителя и процесса-ребенка через pipe , используя для синхронизации сигналы SIGUSR1 и SIGUSR2 , модифицировав программу из раздела. "Прогон программы для организации однонаправленной связи между родственными процессами через pipe " семинара 5.
Задача повышенной сложности : организуйте побитовую передачу целого числа между двумя процессами, используя для этого только сигналы SIGUSR1 и SIGUSR2 .
При реализации нитей исполнения в операционной системе Linux (см. семинары 6–7, начиная с раздела "Понятие о нити исполнения ( thread ) в UNIX . Идентификатор нити исполнения . Функция pthread_self() ") сигналы SIGUSR1 и SIGUSR2 используются для организации синхронизации между процессами, представляющими нити исполнения , и процессом-координатором в служебных целях. Поэтому пользовательские программы, применяющие в своей работе нити исполнения , не могут задействовать сигналы SIGUSR1 и SIGUSR2 .
Завершение порожденного процесса. Системный вызов waitpid(). Сигнал SIGCHLD
В материалах семинаров 3–4 (раздел " Завершение процесса . Функция exit() ") при изучении завершения процесса говорилось о том, что если процесс-ребенок завершает свою работу прежде процесса-родителя, и процесс-родитель явно не указал, что он не заинтересован в получении информации о статусе завершения процесса-ребенка, то завершившийся процесс не исчезает из системы окончательно, а остается в состоянии закончил исполнение ( зомби-процесс ) либо до завершения процесса-родителя, либо до того момента, когда родитель соблаговолит получить эту информацию.
Для получения такой информации процесс-родитель может воспользоваться системным вызовом waitpid() или его упрощенной формой wait() . Системный вызов waitpid() позволяет процессу-родителю синхронно получить данные о статусе завершившегося процесса-ребенка либо блокируя процесс-родитель до завершения процесса-ребенка, либо без блокировки при его периодическом вызове с опцией WNOHANG. Эти данные занимают 16 бит и в рамках нашего курса могут быть расшифрованы следующим образом:
Каждый процесс-ребенок при завершении работы посылает своему процессу-родителю специальный сигнал SIGCHLD , на который у всех процессов по умолчанию установлена реакция "игнорировать сигнал ". Наличие такого сигнала совместно с системным вызовом waitpid() позволяет организовать асинхронный сбор информации о статусе завершившихся порожденных процессов процессом-родителем.
|
Системные вызовы wait() и waitpid() Прототипы системных вызовов #include Описание системных вызовов Это описание не является полным описанием системных вызовов, а адаптировано применительно к нашему курсу. Для получения полного описания обращайтесь к UNIX Manual. Системный вызов waitpid() блокирует выполнение текущего процесса до тех пор, пока либо не завершится порожденный им процесс, определяемый значением параметра pid , либо текущий процесс не получит сигнал , для которого установлена реакция по умолчанию "завершить процесс" или реакция обработки пользовательской функцией. Если порожденный процесс, заданный параметром pid , к моменту системного вызова находится в состоянии закончил исполнение, то системный вызов возвращается немедленно без блокирования текущего процесса. Параметр pid определяет порожденный процесс, завершения которого дожидается процесс-родитель, следующим образом:
Параметр options в нашем курсе может принимать два значения: 0 и WNOHANG . Значение WNOHANG требует немедленного возврата из вызова без блокировки текущего процесса в любом случае. Если системный вызов обнаружил завершившийся порожденный процесс, из числа специфицированных параметром pid , то этот процесс удаляется из вычислительной системы, а по адресу, указанному в параметре status, сохраняется информация о статусе его завершения. Параметр status может быть задан равным NULL , если эта информация не имеет для нас значения. При обнаружении завершившегося процесса системный вызов возвращает его идентификатор. Если вызов был сделан с установленной опцией WNOHANG , и порожденный процесс, специфицированный параметром pid , существует, но еще не завершился, системный вызов вернет значение 0 . Во всех остальных случаях он возвращает отрицательное значение. Возврат из вызова, связанный с возникновением обработанного пользователем сигнала , может быть в этом случае идентифицирован по значению системной переменной errno == EINTR , и вызов может быть сделан снова. Системный вызов wait является синонимом для системного вызова waitpid со значениями параметров pid = -1 , options = 0 . порожденного процесса. /* Программа с асинхронным получением информации о
статусе двух завершившихся порожденных процессов */
#include |
Сигнал или виртуальное прерывание является сообщением, которое система посылает процессу или один процесс посылает другому. Когда процесс получает сигнал, выполнение программы процесса прерывается, и управление передается на подпрограмму (функцию) - обработчик сигнала. После выполнения обработчика сигнала выполнение прерванной программы возобновляется с той точки, на которой она была прервана.
В операционной системе предусмотрено большое число типов сигналов, но большинство из этих типов зарезервировано для системных целей - это сигналы, которые операционная система посылает процессу. Однако есть и сигналы, которыми процессы могут обмениваться между собой.
По умолчанию реакция на большинство сигналов - прекращение процесса, получившего сигнал, то есть, если процесс получает сигнал, обработка которого в нем не предусмотрена, то процесс-получатель сигнала завершается. Однако для большинства типов сигналов процесс может установить обработчик данного сигнала или установить игнорирование данного сигнала.
Если процесс находится в состоянии "добровольного" приостанова (вызванного, например, выполнением системного вызова sleep), то получение сигнала "пробуждает процесс от сна", независимо от того, в чем состояла обработка сигнала, системный вызов sleep заканчивается немедленно.
Обработчик сигнала в процессе имеет вид функции с прототипом:
Void имя_функции (int sigtype);
Параметром данной функции является тип сигнала (один и тот же обработчик может быть установлен для обработки сигналов разных типов).
Для установки своего обработчика сигнала, для его отмены или для установки игнорирования сигнала используется системный вызов signal
Функции-обработчики сигналов – это обычные функции Си, они имеют доступ ко всем глобально видимым переменным и функциям. Однако, поскольку мы не знаем, в какой момент выполнения программы будет вызвана функция-обработчик, мы должны проявлять особую осторожность при обращении к глобальным структурам данных из этой функции. Для функций, обрабатывающих потоки, существует и еще одно важное требование – реентерабильность. Поскольку обработчик сигнала может быть вызван в любой точке выполнения программы (а при не кототорых условиях во время обработки одного сигнала может быть вызван другой обработчик сигнала) в обработчиках додлжны использоваться функции, которые удовлетворяют требованию реентерабельности, то есть, могут быть вызваны в то время, когда они уже вызваны где-то в другой точке программы. Фактически, требование реентерабельности сводится к тому, чтобы функция не использовала никаких глобальных ресурсов, не позаботившись о синхронизации доступа к этим ресурсам. Некоторые функции ввода-вывода, в том числе, функция printf(), реентерабельными не являются. Это значит, что выводу одной функции printf() может помешать вывод другой функции. Ниже приводится список реентерабельных функций, которые безопасно вызвать из обработчиков сигналов.
Список реентерабельных функций
posix_trace_event() | |||
timer_getoverrun() | |||
Процесс может послать сигнал любому другому процессу, PID которого ему известен, при помощи системного вызова kill (несмотря на грозное название, этот системный вызов не обязательно убивает тот процесс, которому он адресован). В некоторых случаях процессу бывает нужно послать сигнал самому себе, это можно сделать при помощи системного вызова raise .
Некоторые типы сигналов
Типы сигналов идентифицируются числовыми номерами, но при программировании часто используются символьные имена сигналов, определенные в системных включаемых файлах. Ниже приведены некоторые наиболее часто употребляемые имена сигналов:
|
Этот сигнал приводит к завершению получившего его процесса. Это единственный сигнал, который не может игнорироваться и для которого нельзя назначить собственный обработчик |
|
|
Этот сигнал - запрос на завершение процесса. Выдачу этого сигнала, например, включает в себя команда (не системный вызов!) kill . Подразумевается, что процесс, получивший этот сигнал, должен завершиться, однако процесс может установить игнорирование этого сигнала или назначить для него собственный обработчик. |
|
|
Этот сигнал система посылает родительскому процессу при завершении любого его дочернего процесса. Реакция на этот сигнал, установленная по умолчанию, - игнорирование. Родительский процесс может не заботиться об обработке этого сигнала, если только он не хочет использовать его для синхронизации своего выполнения с дочерним процессом. |
|
|
Этот сигнал используется для отсчета временных интервалов. Процесс может установить некоторый временной интервал при помощи системных вызовов alarm или setitimer , и по истечении заданного интервала система пошлет ему сигнал SIGALRM . |
|
SIGUSR1 и SIGUSR2 |
|
|
За этими сигналами не зарезенвированы никакие системные назначения. Процессы могут посылать эти сигналы друг другу и интерпретировать их по своему усмотрению. |
|
Более подробно про типы сигналов см. в описании функции
IPC, inter-process communication ). Фактически, сигнал - это асинхронное уведомление процесса о каком-либо событии. Когда сигнал послан процессу, операционная система прерывает выполнение процесса. Если процесс установил собственный обработчик сигнала , операционная система запускает этот обработчик, передав ему информацию о сигнале. Если процесс не установил обработчик, то выполняется обработчик по умолчанию.Названия сигналов «SIG…» являются числовыми константами (макроопределениями Си) со значениями, определяемыми в заголовочном файле signal.h . Числовые значения сигналов могут меняться от системы к системе, хотя основная их часть имеет в разных системах одни и те же значения. Утилита kill позволяет задавать сигнал как числом, так и символьным обозначением.
Посылка сигналов
Сигналы посылаются:
- с терминала, нажатием специальных клавиш или комбинаций (например, нажатие Ctrl-C генерирует SIGINT , Ctrl-\ SIGQUIT , а Ctrl-Z SIGTSTP);
- ядром системы:
- при возникновении аппаратных исключений (недопустимых инструкций, нарушениях при обращении в память, системных сбоях и т. п.);
- ошибочных системных вызовах;
- для информирования о событиях ввода-вывода;
- одним процессом другому (или самому себе), с помощью системного вызова kill() , в том числе:
Сигналы не могут быть посланы завершившемуся процессу, находящемуся в состоянии «зомби» .
Обработка сигналов
Обработчик по умолчанию для большинства сигналов завершает выполнение процесса. Для альтернативной обработки всех сигналов, за исключением SIGKILL и SIGSTOP , процесс может назначить свой обработчик или игнорировать их возникновение модификацией своей сигнальной маски . Единственное исключение - процесс с pid 1 (init), который имеет право игнорировать или обрабатывать любые сигналы, включая KILL и STOP.
Безопасность
Процесс (или пользователь из оболочки) с эффективным UID , не равным 0 (UID суперпользователя), может посылать сигналы только процессам с тем же UID.
Классификация сигналов
POSIX определяет 28 сигналов, которые можно классифицировать следующим образом:
| Название | Код | Действие по умолчанию | Описание | Тип |
|---|---|---|---|---|
| SIGABRT | 6 | Завершение с дампом памяти | Сигнал посылаемый функцией abort() | Управление |
| SIGALRM | 14 | Завершение | Сигнал истечения времени, заданного alarm() | Уведомление |
| SIGBUS | 10 | Завершение с дампом памяти | Неправильное обращение в физическую память | Исключение |
| SIGCHLD | 18 | Игнорируется | Дочерний процесс завершен или остановлен | Уведомление |
| SIGCONT | 25 | Продолжить выполнение | Продолжить выполнение ранее остановленного процесса | Управление |
| SIGFPE | 8 | Завершение с дампом памяти | Ошибочная арифметическая операция | Исключение |
| SIGHUP | 1 | Завершение | Закрытие терминала | Уведомление |
| SIGILL | 4 | Завершение с дампом памяти | Недопустимая инструкция процессора | Исключение |
| SIGINT | 2 | Завершение | Сигнал прерывания (Ctrl-C) с терминала | Управление |
| SIGKILL | 9 | Завершение | Безусловное завершение | Управление |
| SIGPIPE | 13 | Завершение | Запись в разорванное соединение (пайп, сокет) | Уведомление |
| SIGQUIT | 3 | Завершение с дампом памяти | Сигнал «Quit» с терминала (Ctrl-\) | Управление |
| SIGSEGV | 11 | Завершение с дампом памяти | Нарушение при обращении в память | Исключение |
| SIGSTOP | 23 | Остановка процесса | Остановка выполнения процесса | Управление |
| SIGTERM | 15 | Завершение | Сигнал завершения (сигнал по умолчанию для утилиты kill) | Управление |
| SIGTSTP | 20 | Остановка процесса | Сигнал остановки с терминала (Ctrl-Z). | Управление |
| SIGTTIN | 26 | Остановка процесса | Попытка чтения с терминала фоновым процессом | Управление |
| SIGTTOU | 27 | Остановка процесса | Попытка записи на терминал фоновым процессом | Управление |
| SIGUSR1 | 16 | Завершение | Пользовательский сигнал № 1 | Пользовательский |
| SIGUSR2 | 17 | Завершение | Пользовательский сигнал № 2 | Пользовательский |
| SIGPOLL | 22 | Завершение | Событие, отслеживаемое poll() | Уведомление |
| SIGPROF | 29 | Завершение | Истечение таймера профилирования | Отладка |
| SIGSYS | 12 | Завершение с дампом памяти | Неправильный системный вызов | Исключение |
| SIGTRAP | 5 | Завершение с дампом памяти | Ловушка трассировки или брейкпоинт | Отладка |
| SIGURG | 21 | Игнорируется | На сокете получены срочные данные | Уведомление |
| SIGVTALRM | 28 | Завершение | Истечение «виртуального таймера» | Уведомление |
| SIGXCPU | 30 | Завершение с дампом памяти | Процесс превысил лимит процессорного времени | Исключение |
| SIGXFSZ | 31 | Завершение с дампом памяти | Процесс превысил допустимый размер файла | Исключение |
При обработке исключений и отладочных сигналов перед завершением процесс может записать в текущий каталог файл с дампом памяти процесса (англ. core image ), используя который, отладчик может восстановить условия, при которых возникло данное исключение. Иногда (например, для программ, выполняемых от имени суперпользователя) дамп памяти не создаётся из соображений безопасности.
SA_SIGINFO
Обычно обработчик сигнала получает только один аргумент - номер сигнала (это позволяет использовать одну функцию-обработчик для нескольких сигналов). Если при задании обработчика сигнала (функцией sigaction()) указать опцию SA_SIGINFO, то в обработчик будут переданы ещё два аргумента:
- указатель на структуру siginfo_t , включающую:
- битовую маску дополнительных «кодов сигнала», определяющих причину его возникновения;
- идентификатор процесса (PID), пославшего сигнал;
- эффективный идентификатор пользователя (UID), от имени которого выполняется процесс (например, утилита kill), пославший сигнал;
- адрес инструкции, в которой возникло исключение;
- и т. п.
- указатель на «машинный контекст» на момент возникновения сигнала (со «стеком сигнала» - дополнительными данными, которые помещаются в стек при вызове некоторых сигналов-исключений).
Большинство дополнительных кодов специфичны для каждого сигнала. Коды, общие для всех сигналов:
См. также
Напишите отзыв о статье "Сигналы (UNIX)"
Ссылки
- - Концепция сигналов (IEEE Std 1003.1, 2004 Edition)
- - Описание структур и констант, связанных с сигналами (IEEE Std 1003.1, 2004 Edition)
- - «Правила использования сигналов в Unix» (Сообщение в конференции RU.UNIX.PROG)
Отрывок, характеризующий Сигналы (UNIX)
– Целый вечер вам буду петь, – сказала Наташа.– Волшебница всё со мной сделает! – сказал Денисов и отстегнул саблю. Он вышел из за стульев, крепко взял за руку свою даму, приподнял голову и отставил ногу, ожидая такта. Только на коне и в мазурке не видно было маленького роста Денисова, и он представлялся тем самым молодцом, каким он сам себя чувствовал. Выждав такт, он с боку, победоносно и шутливо, взглянул на свою даму, неожиданно пристукнул одной ногой и, как мячик, упруго отскочил от пола и полетел вдоль по кругу, увлекая за собой свою даму. Он не слышно летел половину залы на одной ноге, и, казалось, не видел стоявших перед ним стульев и прямо несся на них; но вдруг, прищелкнув шпорами и расставив ноги, останавливался на каблуках, стоял так секунду, с грохотом шпор стучал на одном месте ногами, быстро вертелся и, левой ногой подщелкивая правую, опять летел по кругу. Наташа угадывала то, что он намерен был сделать, и, сама не зная как, следила за ним – отдаваясь ему. То он кружил ее, то на правой, то на левой руке, то падая на колена, обводил ее вокруг себя, и опять вскакивал и пускался вперед с такой стремительностью, как будто он намерен был, не переводя духа, перебежать через все комнаты; то вдруг опять останавливался и делал опять новое и неожиданное колено. Когда он, бойко закружив даму перед ее местом, щелкнул шпорой, кланяясь перед ней, Наташа даже не присела ему. Она с недоуменьем уставила на него глаза, улыбаясь, как будто не узнавая его. – Что ж это такое? – проговорила она.
Несмотря на то, что Иогель не признавал эту мазурку настоящей, все были восхищены мастерством Денисова, беспрестанно стали выбирать его, и старики, улыбаясь, стали разговаривать про Польшу и про доброе старое время. Денисов, раскрасневшись от мазурки и отираясь платком, подсел к Наташе и весь бал не отходил от нее.
Два дня после этого, Ростов не видал Долохова у своих и не заставал его дома; на третий день он получил от него записку. «Так как я в доме у вас бывать более не намерен по известным тебе причинам и еду в армию, то нынче вечером я даю моим приятелям прощальную пирушку – приезжай в английскую гостинницу». Ростов в 10 м часу, из театра, где он был вместе с своими и Денисовым, приехал в назначенный день в английскую гостинницу. Его тотчас же провели в лучшее помещение гостинницы, занятое на эту ночь Долоховым. Человек двадцать толпилось около стола, перед которым между двумя свечами сидел Долохов. На столе лежало золото и ассигнации, и Долохов метал банк. После предложения и отказа Сони, Николай еще не видался с ним и испытывал замешательство при мысли о том, как они свидятся.
Светлый холодный взгляд Долохова встретил Ростова еще у двери, как будто он давно ждал его.
– Давно не видались, – сказал он, – спасибо, что приехал. Вот только домечу, и явится Илюшка с хором.
– Я к тебе заезжал, – сказал Ростов, краснея.
Долохов не отвечал ему. – Можешь поставить, – сказал он.
Ростов вспомнил в эту минуту странный разговор, который он имел раз с Долоховым. – «Играть на счастие могут только дураки», сказал тогда Долохов.
– Или ты боишься со мной играть? – сказал теперь Долохов, как будто угадав мысль Ростова, и улыбнулся. Из за улыбки его Ростов увидал в нем то настроение духа, которое было у него во время обеда в клубе и вообще в те времена, когда, как бы соскучившись ежедневной жизнью, Долохов чувствовал необходимость каким нибудь странным, большей частью жестоким, поступком выходить из нее.
Ростову стало неловко; он искал и не находил в уме своем шутки, которая ответила бы на слова Долохова. Но прежде, чем он успел это сделать, Долохов, глядя прямо в лицо Ростову, медленно и с расстановкой, так, что все могли слышать, сказал ему:
– А помнишь, мы говорили с тобой про игру… дурак, кто на счастье хочет играть; играть надо наверное, а я хочу попробовать.
«Попробовать на счастие, или наверное?» подумал Ростов.
– Да и лучше не играй, – прибавил он, и треснув разорванной колодой, прибавил: – Банк, господа!
Придвинув вперед деньги, Долохов приготовился метать. Ростов сел подле него и сначала не играл. Долохов взглядывал на него.
– Что ж не играешь? – сказал Долохов. И странно, Николай почувствовал необходимость взять карту, поставить на нее незначительный куш и начать игру.
– Со мной денег нет, – сказал Ростов.
– Поверю!
Ростов поставил 5 рублей на карту и проиграл, поставил еще и опять проиграл. Долохов убил, т. е. выиграл десять карт сряду у Ростова.
– Господа, – сказал он, прометав несколько времени, – прошу класть деньги на карты, а то я могу спутаться в счетах.
Один из игроков сказал, что, он надеется, ему можно поверить.
– Поверить можно, но боюсь спутаться; прошу класть деньги на карты, – отвечал Долохов. – Ты не стесняйся, мы с тобой сочтемся, – прибавил он Ростову.
Игра продолжалась: лакей, не переставая, разносил шампанское.
Все карты Ростова бились, и на него было написано до 800 т рублей. Он надписал было над одной картой 800 т рублей, но в то время, как ему подавали шампанское, он раздумал и написал опять обыкновенный куш, двадцать рублей.
– Оставь, – сказал Долохов, хотя он, казалось, и не смотрел на Ростова, – скорее отыграешься. Другим даю, а тебе бью. Или ты меня боишься? – повторил он.
Ростов повиновался, оставил написанные 800 и поставил семерку червей с оторванным уголком, которую он поднял с земли. Он хорошо ее после помнил. Он поставил семерку червей, надписав над ней отломанным мелком 800, круглыми, прямыми цифрами; выпил поданный стакан согревшегося шампанского, улыбнулся на слова Долохова, и с замиранием сердца ожидая семерки, стал смотреть на руки Долохова, державшего колоду. Выигрыш или проигрыш этой семерки червей означал многое для Ростова. В Воскресенье на прошлой неделе граф Илья Андреич дал своему сыну 2 000 рублей, и он, никогда не любивший говорить о денежных затруднениях, сказал ему, что деньги эти были последние до мая, и что потому он просил сына быть на этот раз поэкономнее. Николай сказал, что ему и это слишком много, и что он дает честное слово не брать больше денег до весны. Теперь из этих денег оставалось 1 200 рублей. Стало быть, семерка червей означала не только проигрыш 1 600 рублей, но и необходимость изменения данному слову. Он с замиранием сердца смотрел на руки Долохова и думал: «Ну, скорей, дай мне эту карту, и я беру фуражку, уезжаю домой ужинать с Денисовым, Наташей и Соней, и уж верно никогда в руках моих не будет карты». В эту минуту домашняя жизнь его, шуточки с Петей, разговоры с Соней, дуэты с Наташей, пикет с отцом и даже спокойная постель в Поварском доме, с такою силою, ясностью и прелестью представились ему, как будто всё это было давно прошедшее, потерянное и неоцененное счастье. Он не мог допустить, чтобы глупая случайность, заставив семерку лечь прежде на право, чем на лево, могла бы лишить его всего этого вновь понятого, вновь освещенного счастья и повергнуть его в пучину еще неиспытанного и неопределенного несчастия. Это не могло быть, но он всё таки ожидал с замиранием движения рук Долохова. Ширококостые, красноватые руки эти с волосами, видневшимися из под рубашки, положили колоду карт, и взялись за подаваемый стакан и трубку.
Многие программы Unix принимают сигналы типа USR1 и USR2 . Например, чтобы обновить исполняемый файл для Nginx "на лету", вы отправляете kill -USR2 .
Я понимаю, что USR1 является "определяемым пользователем" сигналом, что означает, что тот, кто создал программу, может использовать его для обозначения "выключить" или "выгрузить ваши журналы" или "распечатать foo тысячу раз" или что-то еще. Но я не понимаю, почему они должны использовать это произвольное имя. Почему бы не kill -UPGRADE , или kill -GRACEFUL_SHUTDOWN ? Имеет ли Unix только определенные сигналы?
Пока мы это делаем, Nginx также использует следующие сигналы (см. документация):
- TERM, INT : быстрое отключение
- QUIT : изящное завершение работы
- HUP
:
- Конфигурация перезагрузки
- Запустите новые рабочие процессы с новой конфигурацией
- Изящное завершение работы старых рабочих процессов
- USR1 : откройте файлы журнала
- USR2 : обновление исполняемых на лету
- WINCH : изящное завершение рабочих процессов
HUP? Winch? Какая причина этих имен? Где я могу узнать больше об этом?
6 ответов
Сигналы, доступные в ОС, определяются ОС (обычно после POSIX) - они не являются "строками", а целыми константами со стандартными именами. USR1 и USR2 - это два сигнала, которые не имеют конкретного значения, предназначенные для любого произвольного использования, которое хочет разработчик.
На вашей машине linux прочитайте man 7 signal для обзора обработки сигналов и сигналов.
Вы можете переопределить значение других сигналов, если вы готовы работать с ОС, выдавая эти сигналы в ответ на события. Вы можете, например, make HUP означает "перезагрузить конфигурацию" - если вы либо уверены, что процесс никогда не получит зависания (потеря терминала), либо вы готовы обрабатывать случаи, когда ОС, а не пользователь, посылает сигнал HUP.
HUP не подходит для "зависания". Этот сигнал отправляется процессу, если его управляющий терминал достигает конца файла. В прежние времена управляющие терминалы обычно подключались к последовательным портам, возможно, через модемную линию по телефонной линии. Если телефонное соединение было повёрнуто, локальный модем снизит линию Carrier Detect, что приведет к отправке отчета о завершении файла ядра и передаваемого сигнала SIGHUP .
WINCH не подходит для "изменения окна". Он отправляется процессу, если его управляющий терминал изменяет размер. По понятным причинам терминалы, которые могут изменять размер, обычно представляют собой псевдотерминалы, которые в конечном счете представлены терминальным эмулятором, работающим в среде окон (например, xterm).
Поскольку имена сигналов стандартизируются (POSIX). Вы можете написать свой собственный исполняемый файл kill-типа, чтобы взять -UPGRADE , если хотите, и доставить сигнал USR1 , но стандартный kill , который поставляется с UNIX, не узнает его.
В качестве альтернативы вы можете создать псевдоним, функцию или оболочку script для выполнения перевода для вас, например, с помощью псевдонима bash:
Alias upgrade="kill -USR1"
Файл заголовка signal.h сопоставляет имена сигналов с их фактическими значениями, зависящими от реализации.
В терминах WINCH я считаю это немного мерзостью. Это сигнал, который доставляется приложениям при изменении размера окна (особенно когда изменяется окно их управляющего терминала).
Использование этого для изящного закрытия рабочих потоков не является хорошей идеей, если вы не можете гарантировать, что процесс никогда не будет работать в терминале. Я знаю, что был бы очень миф, если бы я запускал приложение, и он решил отменить всю работу в полете только потому, что я максимизировал окно: -)
Попробуйте 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 16) SIGSTKFLT 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 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX
В этом разделе поэтапно рассмотрим процесс обработки сигналов (таких как прерывания), поступающих из внешнего мира, а также ошибок программы. Ошибки программ возникают в основном из-за непра-
вильных обращений к памяти, при выполнении специфических инст рукций или из-за операций с плавающей точкой. Наиболее распространенные сигналы, поступающие из внешнего мира: прерывание (interrupt ) – этот сигнал посылается, когда вы нажимаете клавишу DEL ; выход (quit )– порождается символом FS (ctl -\); отключение (hangup ) – вызван тем, что повешена телефонная трубка, и завершение (terminate ) – порождается командой kill. Когда происходит одно из вышеуказанных событий, сигнал посылается всем процессам, запу щенным с данного терминала, и если не существует соглашений, пред писывающих иное, сигнал завершает процесс. Для большинства сигналов создается дамп памяти, который может потребоваться для отладки. (См. adb(1) и sdb(l).)
Системный вызов signal изменяет действие, выполняемое по умолчанию. Он имеет два аргумента: первый – это номер, который определяет сигнал, второй – это или адрес функции, или же код, предписывающий игнорировать сигнал или восстанавливать действия по умолчанию. Файл
#include
signal(SIGINT, SIG_IGN);
приводит к игнорированию прерывания, в то время как
signal(SIGINT, SIG_DFL);
восстанавливает действие по умолчанию – завершение процесса. Во всех случаях signal возвращает предыдущее значение сигнала. Если второй аргумент – это имя функции (которая должна быть объявлена в этом же исходном файле), то она будет вызвана при возникновении сигнала. Чаще всего эта возможность используется для того, чтобы позволить программе подготовиться к выходу, например удалить временный файл:
#include
char *tempfile = "temp.XXXXXX";
extern onintr();
mktemp(tempfile);
/* Обработка … */ exit(0);
onintr() /* очистить в случае прерывания */
unlink(tempfile); exit(1);
Зачем нужны проверка и повторный вызов signal в main? Вспомните, что сигналы посылаются во все процессы, запущенные на данном терминале. Соответственно, когда программа запущена не в интерактивном режиме (а с помощью &), командный процессор позволяет ей игно рировать прерывания, таким образом, программа не будет остановлена прерываниями, предназначенными для не фоновых процессов. Если же программа начинается с анонсирования того, что все прерывания должны быть посланы в onintr, невзирая ни на что, это сводит на нет попытки командного процессора защитить программу, работающую в фоновом режиме.
Решение, представленное выше, позволяет проверить состояние управления прерываниями и продолжать игнорировать прерывания, если они игнорировались ранее. Код учитывает тот факт, что signal возвращает предыдущее состояние конкретного сигнала. И если сигналы ранее игнорировались, процесс будет и далее их игнорировать; в противном случае они должны быть перехвачены.
В более сложной программе может потребоваться перехватить прерывание и интерпретировать его как запрос на отмену выполняемой операции и возврат в ее собственный цикл обработки команд. Возьмем, например, текстовый редактор: прерывание слишком долгой печати не должно приводить к выходу из программы и потере всей сделанной работы. В этой ситуации можно написать такой код:
#include
#include
if (signal(SIGINT, SIG_IGN) != SIG_IGN) signal(SIGINT, onintr);
setjmp(sjbuf); /* сохранение текущей позиции в стеке*/ for (;;) {
/* основной цикл обработки */
onintr() /* переустановить в случае прерывания */
signal(SIGINT, onintr); /* переустановить для следующего прерывания */ printf("\nInterrupt\n");
longjmp(sjbuf, 0); /* возврат в сохраненное состояние */ }
Файл setjmp.h объявляет тип jmp_buf как объект, в котором может сохраняться положение стека; sjbuf объявляется как объект такого типа. Функция setjmp(3) сохраняет запись о месте выполнения программы. Значения переменных не сохраняются. Когда происходит прерывание, инициируется обращение к программе onintr, которая может напечатать сообщение, установить флаги или сделать что-либо другое. Функция longjmp получает объект, сохраненный в setjmp, и возвращает управление в точку программы, следующую за вызовом setjmp. Таким образом, управление (и положение стека) возвращаются к тому месту основной программы, где происходит вход в основной цикл.
Обратите внимание на то, что сигнал снова устанавливается в onintr, после того как произойдет прерывание. Это необходимо, так как сигналы при их получении автоматически восстанавливают действие по умолчанию.
Некоторые программы просто не могут быть остановлены в произвольном месте, например в процессе обработки сложной структуры данных, поэтому необходимо иметь возможность обнаруживать сигналы. Возможно следующее решение – надо сделать так, чтобы программа обработки прерываний установила флаг и возвратилась обратно вместо того, чтобы вызывать exit или longjmp. Выполнение будет продолжено с того самого места, в котором оно было прервано, а флаг прерывания может быть проверен позже.
С таким подходом связана одна трудность. Предположим, что программа читает с терминала в то время, когда послано прерывание. Надлежащим образом вызывается указанная подпрограмма, которая устанавливает флаги и возвращается обратно. Если бы дело действительно обстояло так, как было указано выше, то есть выполнение программы возобновлялось бы «с того самого места, где оно было прервано», то программа должна была бы продолжать читать с терминала до тех пор, пока пользователь не напечатал бы новую строку. Такое поведение может сбивать с толку, ведь пользователь может и не знать, что программа читает, и он, вероятно, предпочел бы, чтобы сигнал вступал в силу незамедлительно. Чтобы разрешить эту проблему, система завершает чтение, но со статусом ошибки, который указывает, что произошло; errno устанавливается в EINTR, определенный в errno.h, чтобы обозначить прерванный системный вызов.
Поэтому программы, которые перехватывают сигналы и возобновляют работу после них, должны быть готовы к «ошибкам», вызванным прерванными системными вызовами. (Системные вызовы, по отношению к которым надо проявлять осторожность, – это чтение с терминала, ожидание и пауза). Такая программа может использовать код, приведенный ниже, для чтения стандартного ввода:
#include
if (read(0, &c, 1) <= 0) /* EOF или прерывание */
if (errno == EINTR) { /* EOF, вызванный прерыванием */ errno = 0; /* переустановить для следующего раза */
} else { /* настоящий конец файла */
И последняя тонкость, на которую надо обратить внимание, если перехват сигналов сочетается с выполнением других программ. Предположим, что программа обрабатывает прерывания и, к тому же, содержит метод (как! в ed), посредством которого могут выполняться другие программы. Тогда код будет выглядеть примерно так:
if (fork() == 0) execlp(…);
signal(SIGINT, SIG_IGN); /* предок игнорирует прерывания */
wait(&status); /* пока выполняется потомок */ signal(SIGINT, onintr); /* восстановить прерывания */
Почему именно так? Сигналы посылаются всем вашим процессам. Предположим, что программа, которую вы вызвали, обрабатывает свои собственные прерывания, как это делает редактор. Если вы прерываете дочернюю программу, она получит сигнал и вернется в свой основной цикл, и, вероятно, прочитает ваш терминал. Но вызывающая программа также выйдет из состояния ожидания дочерней программы и прочитает ваш терминал. Наличие двух процессов чтения терминала все запутывает, так как на самом деле система «подкидывает монетку», чтобы решить, какая программа получит каждую из строк ввода. Чтобы избежать этого, родительская программа должна игнорировать прерывания до тех пор, пока не выполнится дочерняя. Это умозаключение отражено в обработке сигналов в system:
#include
system(s) /* выполнить командную строку s */ char *s;
int status, pid, w, tty;
int (*istat)(), (*qstat)();
if ((pid = fork()) == 0) {
execlp("sh", "sh", "–c", s, (char *) 0); exit(127);
istat = signal(SIGINT, SIG_IGN); qstat = signal(SIGQUIT, SIG_IGN);
while ((w = wait(&status)) != pid && w != –1)
if (w == –1) status = –1;
signal(SIGINT, istat); signal(SIGQUIT, qstat); return status;
В отступление от описания, функция signal очевидно имеет несколько странный второй аргумент. На самом деле это указатель на функцию, которая возвращает целое число, и это также тип самой функции sig– nal. Два значения, SIG_IGN и SIG_DFL, имеют правильный тип, но выби раются таким образом, чтобы они не совпадали ни с какими возможными реальными функциями. Для особо интересующихся приведем пример того, как они описываются для PDP-11 и VAX; описания должны быть достаточно отталкивающими, чтобы побудить к использованию signal.h.
#define SIG_DFL (int (*)())0
#define SIG_IGN (int (*)())1
Сигналы alarm
Системный вызов alarm(n ) вызывает отправку вашему процессу сигнала SIGALRM через n секунд. Сигнал alarm может применяться для того, чтобы убедиться, что нечто произошло в течение надлежащего проме жутка времени если что-то произошло, SIGALRM может быть выключен, если же нет, то процесс может вернуть управление, получив сигнал alarm.
Чтобы пояснить ситуацию, рассмотрим программу, называемую time– out, она запускает некоторую другую команду; если эта команда не закончилась к определенному времени, она будет аварийно прервана, когда alarm выключится. Например, вспомните команду watchfor из главы 5. Вместо того чтобы запускать ее на неопределенное время, можно установить часовой лимит:
$ timeout -3600 watchfor dmg &
Код в timeout иллюстрирует практически все, о чем говорилось в двух предыдущих разделах. Потомок создан; предок устанавливает аварийный сигнал и ждет, пока потомок закончит свою работу. Если alarm приходит раньше, то потомок уничтожается. Предпринимается попытка вернуть статус выхода потомка.
/* timeout: устанавливает временное ограничение для процесса */
#include
#include
int pid; /* идентификатор дочернего процесса */
char *progname; main(argc, argv)
int sec = 10, status, onalarm();
progname = argv;
if (argc > 1 && argv == ‘–’) { sec = atoi(&argv);
argc––; argv++;
if (argc < 2)
error("Usage: %s [–10] command", progname); if ((pid=fork()) == 0) {
execvp(argv, &argv); error("couldn’t start %s", argv);
signal(SIGALRM, onalarm); alarm(sec);
if (wait(&status) == –1 || (status & 0177) != 0) error("%s killed", argv);
exit((status >> 8) & 0377);
onalarm() /* завершить дочерний процесс в случае получения alarm */
kill(pid, SIGKILL);
Упражнение 7.18. Можете ли вы предположить, как реализован sleep? Подсказка: pause(2). При каких условиях (если такие условия существуют) sleep и alarm могут создавать помехи друг для друга? ~
История и библиография
В книге не представлено подробного описания реализации системы UNIX, в частности из-за того, что существуют имущественные права на код. Доклад Кена Томпсона (Ken Thompson) «UNIX implementation» (Реализация UNIX), изданный в «BSTJ» в июле 1978 года, описывает основные идеи. Эту же тему поднимают статьи «The UNIX system – a retrospective» (Система UNIX в ретроспективе) в том же номере
«BSTJ» и «The evolution of the UNIX time-sharing system» (Эволюция UNIX – системы разделения времени), напечатанная в материалах Symposium on Language Design and Programming Methodology в журнале издательства Springer-Verlag «Lecture Notes in Computer Science»
№ 79 в 1979 году. Оба труда принадлежат перу Денниса Ритчи (Dennis Ritchie).
Программа readslow была придумана Питером Вейнбергером (Peter Weinberger) в качестве простого средства для демонстрации зрителям игры шахматной программы Belle Кена Томсона и Джо Кондона (Joe Condon) во время шахматного турнира. Belle записывала состояние игры в файл; наблюдатели опрашивали файл с помощью readslow, чтобы не занимать слишком много драгоценных циклов. (Новая версия оборудования для Belle осуществляет небольшие расчеты на своей главной машине, поэтому больше такой проблемы не существует.)
Том Дафф (Tom Duff) вдохновил нас на написание spname. Статья Айво ра Дерхема (Ivor Durham), Дэвида Лэмба (David Lamb) и Джеймса Сакса (James Saxe) «Spelling correction in user interfaces» (Проверка орфографии в пользовательских интерфейсах), изданная CACM в октябре 1983 года, представляет несколько отличающийся от привычного проект реализации исправления орфографических ошибок в контексте почтовой программы.