Сигналы в linux. Примеры

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, то в обработчик будут переданы ещё два аргумента:

1. указатель на структуру siginfo_t , включающую:
   • битовую маску дополнительных «кодов сигнала», определяющих причину его возникновения;
   • идентификатор процесса (PID), пославшего сигнал;
   • эффективный идентификатор пользователя (UID), от имени которого выполняется процесс (например, утилита kill), пославший сигнал;
   • адрес инструкции, в которой возникло исключение;
   • и т. п.
2. указатель на «машинный контекст» на момент возникновения сигнала (со «стеком сигнала» - дополнительными данными, которые помещаются в стек при вызове некоторых сигналов-исключений).

Большинство дополнительных кодов специфичны для каждого сигнала. Коды, общие для всех сигналов:

См. также

Напишите отзыв о статье "Сигналы (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

Рассмотрим теперь другую программу – 13–14-3.c :

/* Программа с пользовательской обработкой сигнала SIGINT */ #include #include /* Функция my_handler – пользовательский обработчик сигнала */ void my_handler(int nsig){ printf("Receive signal %d, CTRL-C pressed\n", nsig); } int main(void){ /* Выставляем реакцию процесса на сигнал SIGINT */ (void)signal(SIGINT, my_handler); /*Начиная с этого места, процесс будет печатать сообщение о возникновении сигнала SIGINT */ while(1); return 0; } Листинг 13-14.3. Программа (13–14-3.c) с пользовательской обработкой сигнала SIGINT.

Эта программа отличается от программы из раздела "Прогон программы, игнорирующей сигнал SIGINT " тем, что в ней введена обработка сигнала SIGINT пользовательской функцией. Наберите, откомпилируйте и запустите эту программу, проверьте ее реакцию на нажатие клавиш < CTRL > и и на нажатие клавиш < CTRL > и <4>.

Модификация предыдущей программы для пользовательской обработки сигналов SIGINT и SIGQUIT

Модифицируйте программу из предыдущего раздела так, чтобы она печатала сообщение и о нажатии клавиш < CTRL > и <4>. Используйте одну и ту же функцию для обработки сигналов SIGINT и SIGQUIT . Откомпилируйте и запустите ее, проверьте корректность работы. Снимать программу также придется с другого терминала командой kill .

Восстановление предыдущей реакции на сигнал

До сих пор в примерах мы игнорировали значение , возвращаемое системным вызовом signal() . На самом деле этот системный вызов возвращает указатель на предыдущий обработчик сигнала , что позволяет восстанавливать переопределенную реакцию на сигнал . Рассмотрим пример программы 13-14-4.c , возвращающей первоначальную реакцию на сигнал SIGINT после 5 пользовательских обработок сигнала .

/* Программа с пользовательской обработкой сигнала SIGINT, возвращающаяся к первоначальной реакции на этот сигнал после 5 его обработок*/ #include #include int i=0; /* Счетчик числа обработок сигнала */ void (*p)(int); /* Указатель, в который будет занесен адрес предыдущего обработчика сигнала */ /* Функция my_handler – пользовательский обработчик сигнала */ void my_handler(int nsig){ printf("Receive signal %d, CTRL-C pressed\n", nsig); i = i+1; /* После 5-й обработки возвращаем первоначальную реакцию на сигнал */ if(i == 5) (void)signal(SIGINT, p); } int main(void){ /* Выставляем свою реакцию процесса на сигнал SIGINT, запоминая адрес предыдущего обработчика */ p = signal(SIGINT, my_handler); /*Начиная с этого места, процесс будет 5 раз печатать сообщение о возникновении сигнала SIGINT */ while(1); return 0; } Листинг 13-14.4. Программа (13-14-4.c) с пользовательской обработкой сигнала SIGINT.

Наберите, откомпилируйте программу и запустите ее на исполнение .

Сигналы 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 #include pid_t waitpid(pid_t pid, int *status, int options); pid_t wait(int *status); Описание системных вызовов Это описание не является полным описанием системных вызовов, а адаптировано применительно к нашему курсу. Для получения полного описания обращайтесь к UNIX Manual. Системный вызов waitpid() блокирует выполнение текущего процесса до тех пор, пока либо не завершится порожденный им процесс, определяемый значением параметра pid , либо текущий процесс не получит сигнал , для которого установлена реакция по умолчанию "завершить процесс" или реакция обработки пользовательской функцией. Если порожденный процесс, заданный параметром pid , к моменту системного вызова находится в состоянии закончил исполнение, то системный вызов возвращается немедленно без блокирования текущего процесса. Параметр pid определяет порожденный процесс, завершения которого дожидается процесс-родитель, следующим образом: Если pid > 0 ожидаем завершения процесса с идентификатором pid . Если pid = 0 , то ожидаем завершения любого порожденного процесса в группе , к которой принадлежит процесс-родитель. Если pid = -1 , то ожидаем завершения любого порожденного процесса. Если pid < 0 , но не –1 , то ожидаем завершения любого порожденного процесса из группы , идентификатор которой равен абсолютному значению параметра pid . Параметр options в нашем курсе может принимать два значения: 0 и WNOHANG . Значение WNOHANG требует немедленного возврата из вызова без блокировки текущего процесса в любом случае. Если системный вызов обнаружил завершившийся порожденный процесс, из числа специфицированных параметром pid , то этот процесс удаляется из вычислительной системы, а по адресу, указанному в параметре status, сохраняется информация о статусе его завершения. Параметр status может быть задан равным NULL , если эта информация не имеет для нас значения. При обнаружении завершившегося процесса системный вызов возвращает его идентификатор. Если вызов был сделан с установленной опцией WNOHANG , и порожденный процесс, специфицированный параметром pid , существует, но еще не завершился, системный вызов вернет значение 0 . Во всех остальных случаях он возвращает отрицательное значение. Возврат из вызова, связанный с возникновением обработанного пользователем сигнала , может быть в этом случае идентифицирован по значению системной переменной errno == EINTR , и вызов может быть сделан снова. Системный вызов wait является синонимом для системного вызова waitpid со значениями параметров pid = -1 , options = 0 . порожденного процесса. /* Программа с асинхронным получением информации о статусе двух завершившихся порожденных процессов */ #include #include #include #include #include /* Функция my_handler – обработчик сигнала SIGCHLD */ void my_handler(int nsig){ int status; pid_t pid; /* Опрашиваем статус завершившегося процесса и одновременно узнаем его идентификатор */ if((pid = waitpid(-1, &status, 0)) < 0){ /* Если возникла ошибка – сообщаем о ней и продолжаем работу */ printf("Some error on waitpid errno = %d\n", errno); } else { /* Иначе анализируем статус завершившегося процесса */ if ((status & 0xff) == 0) { /* Процесс завершился с явным или неявным вызовом функции exit() */ printf("Process %d was exited with status %d\n", pid, status >> 8); } else if ((status & 0xff00) == 0){ /* Процесс был завершен с помощью сигнала */ printf("Process %d killed by signal %d %s\n", pid, status &0x7f,(status & 0x80) ? "with core file" : "without core file"); } } } int main(void){ pid_t pid; /* Устанавливаем обработчик для сигнала SIGCHLD */ (void) signal(SIGCHLD, my_handler); /* Порождаем Сhild 1 */ if((pid = fork()) < 0){ printf("Can\"t fork child 1\n"); exit(1); } else if (pid == 0){ /* Child 1 – завершается с кодом 200 */ exit(200); } /* Продолжение процесса-родителя – порождаем Сhild 2 */ if((pid = fork()) < 0){ printf("Can\"t fork child 2\n"); exit(1); } else if (pid == 0){ /* Child 2 – циклится, необходимо удалять с помощью сигнала! */ while(1); } /* Продолжение процесса-родителя – уходим в цикл */ while(1); return 0; } Листинг 13-14.5. Программа (13-14-5.c) с асинхронным получением информации о статусе двух завершившихся порожденных процессов. kill с каким-либо номером сигнала . Родительский процесс также будет необходимо завершать командой kill .

Сигналы - это запросы на прерывание, реализуемые на уровне процессов. Определено свыше тридцати различных сигналов, и они находят самое разное применение.

• Сигналы могут посылаться между процессами как средство коммуникации.
• Сигналы могут посылаться драйвером терминала для уничтожения или приостановки процессов, когда пользователь нажимает специальные комбинации клавиш, такие как или .
• Сигналы могут посылаться в самых разных целях пользователем или администратором с помощью команды kill.
• Сигналы могут посылаться ядром, когда процесс выполняет нелегальную инструкцию, например деление на нуль.
• Сигналы могут посылаться ядром для уведомления процесса о "представляющем интерес" событии, таком как прекращение дочернего процесса или доступность данных в канале ввода-вывода.
• Дамп памяти - это файл, содержащий образ памяти процесса. Его можно использовать для отладки.

Функции, связанные с этими комбинациями клавиш, могут назначаться другим клавишам помощью команды stty, но на практике такое встречается очень редко. Мы подразумеваем, что с данными клавишами связаны их стандартные функции. Когда поступает сигнал, возможен один из двух вариантов развития событий. Если процесс назначил сигналу подпрограмму обработки, то после вызова ей предоставляется информация о контексте, в котором был сгенерирован сигнал. В противном случае ядро выполняет от имени процесса действия, заданные по умолчанию. Эти действия зависят от сигнала. Многие сигналы приводят к завершению процесса, а в некоторых случаях при этом еще и создается дамп памяти. Процедура вызова обработчика называется перехватом сигнала. Когда выполнение обработчика завершается, процесс возобновляется с той точки, где был получен сигнал. Для того чтобы определенные сигналы не поступали в программу, нужно задать их игнорирование или блокирование. Игнорируемый сигнал просто пропускается и не влияет на работу процесса. Блокируемый сигнал ставится в очередь на обработку, но ядро не требует от процесса никаких действий до явного разблокирования сигнала. Обработчик вызывается для разблокированного сигнала только один раз, даже если в течение периода блокировки поступило несколько аналогичных сигналов. Ниже перечислены сигналы, которые должны быть известны любому системному администратору. Традиционно имена сигналов записываются прописными буквами. Иногда к именам добавляется префикс SIG (например, SIGHUP). № Имя Описание Реакция Перехваты- Блоки- Дамп умолчанию 1 HUP Отбой Завершение Да Да Нет 2 INT Прерывание Завершение Да Да Нет 3 QUIT Выход Завершение Да Да Да 9 KILL Уничтожение Завершение Нет Нет Нет 10 BUS Ошибка на шине Завершение Да Да Да 11 SEGV Ошибка сегментации Завершение Да Да Да 12 TERM Запрос на завершение завершение Да Да Нет 13 STOP Останов Останов Нет Нет Нет 14 TSTP Сигнал останова, посылаемый Останов Да Да Нет с клавиатуры 15 CONT Продолжение после останова Игнорируется Да Нет Нет 16 WINCH Изменение окна Игнорируется Да Да Нет 17 USR1 Определяется пользователем Завершение Да Да Нет 18 USR2 Определяется пользователем Завершение Да Да Нет Существуют и другие сигналы, не показанные в табл. 5.1; большинство из них сообщает о всяких загадочных ошибках, например "неверная инструкция". По умолчанию такие сигналы, как правило, приводят к завершению программы и созданию дампа памяти. Перехват и блокирование сигналов обычно разрешены, так как есть достаточно "умные" программы, устраняющие последствия ошибок. Сигналы BUS и segv также посылаются при возникновении ошибок. Мы включили их в таблицу, поскольку они чрезвычайно распространены: обычно программа аварийно завершается именно из-за них. Сами по себе эти сигналы не имеют диагностической ценности. Они лишь указывают на факт неправильного обращения к памяти6. Сигналы KILL и STOP нельзя ни перехватить, ни заблокировать, ни проигнорировать. Сигнал KILL приводит к уничтожению процесса, которому он посылается, а сигнал STOP приостанавливает выполнение процесса до получения сигнала CONT. Сигнал CONT можно перехватить и проигнорировать, но нельзя заблокировать. Сигнал tstp представляет собой более "гибкую" версию сигнала STOP. Проще всего описать его как запрос на останов. Он генерируется драйвером терминала при нажатии пользователем комбинации клавиш . Программы, перехватывающие этот сигнал, обычно выполняют операции очистки, а затем посылают сами себе сигнал STOP. С другой стороны, программы могут игнорировать сигнал TSTP, чтобы их нельзя было остановить командой с клавиатуры. Эмуляторы терминалов посылают сигнал WINCH, когда происходит изменение их конфигурационных параметров (например, числа строк на виртуальном терминале). Это позволяет программам, которые взаимодействуют с эмуляторами, таким как текстовые редакторы, автоматически переконфигурировать себя в ответ на изменения. Если размер окна не удается правильно изменить, убедитесь в том, что сигнал WINCH генерируется и корректно обрабатывается. Хотя назначение сигналов KILL, INT, TERM, HUP и QUIT может показаться одинаковым, в действительности они совершенно различны.

• Сигнал KILL не блокируется и приводит к безусловному завершению процесса на уровне ядра. По сути, процесс не успевает даже принять этот сигнал.
• Сигнал INT посылается драйвером терминала при нажатии пользователем комбинации клавиш и служит запросом на завершение текущей операции. Перехватив этот сигнал, простые программы должны завершить работу или позволить уничтожить себя стандартному обработчику сигнала. Программы, в которых есть интерактивный режим командной строки, должны прекратить текущую операцию, выполнить очистку и снова перейти в режим ожидания.
• Сигнал TERM представляет собой запрос на завершение программы. Предполагается, что процесс, получивший этот сигнал, осуществляет очистку и завершается.
• У сигнала HUP есть две распространенные интерпретации. Во-первых, многие демоны воспринимают его как команду сброса. Если демон способен повторно про честь свой конфигурационный файл и адаптироваться к изменениям без перезапуска, сигнал HUP позволяет менять его поведение.
• Во-вторых, этот сигнал иногда генерируется драйвером терминала при попытке уничтожить связанные с терминалом процессы. В основном это поведение сохранилось со времен использования проводных соединений терминалов и модемов. Отсюда и название "отбой".
• Интерпретаторы семейства csh (tcsh и другие) обычно делают фоновые процессы невосприимчивыми к сигналу HUP, чтобы они могли продолжать свою работу, даже когда пользователь выходит из системы. Пользователи интерпретаторов семейства sh (ksh, bash и так далее) могут эмулировать такое поведение с помощью команды nohup.
• Сигнал QUIT напоминает сигнал TERM, за исключением того, что по умолчанию стандартный обработчик создает дамп памяти.

Сигналы USR1 и USR2 не имеют стандартного назначения. Ими можно пользоваться в различных целях. Например, веб-сервер Apache интерпретирует сигнал USR1 как запрос на перезапуск. Отправка сигналов: команда kill Команду kill чаще всего используют для уничтожения процессов. Эта команда может послать процессу любой сигнал, но по умолчанию это сигнал TERM. Команду kill могут выполнять как рядовые пользователи (для своих собственных процессов), так и суперпользователь (для любого процесса). Она имеет следующий синтаксис: kill [-сигнал] идентификатор, где сигнал - это номер или символическое имя посылаемого сигнала, а идентификатор - номер искомого процесса. Команда kill без номера сигнала не гарантирует, что процесс будет уничтожен, поскольку сигнал TERM можно перехватывать, блокировать и игнорировать. Команда kill -9 идентификатор "гарантированно" уничтожает процесс, так как сигнал с номером 9 (KILL) не перехватывается. Используйте команду kill -9 только в случае, если "вежливый" запрос на завершение программы не был выполнен. Мы написали слово "гарантированно" в кавычках, так как иногда процессы переходят в такое состояние, в котором их нельзя завершить даже таким способом (обычно это связано с блокировкой ввода-вывода, например, при остановке жесткого диска). Единственный выход в такой ситуации - перезагрузка. Команда killall выполняет различные функции в системах UNIX и Linux. В Linux команда killall уничтожает процессы, заданные именем. Например, следующая команда уничтожает все процессы веб-сервера Apache. ubuntu$ sudo killall httpd Стандартная UNIX-команда killall, предусмотренная в дистрибутивах Solaris, HP-UX и AIX, не принимает параметры и просто уничтожает все процессы текущего пользователя. Ее выполнение от имени суперпользователя приведет к уничтожению процесса init и выключению компьютера. Ух! Команды pgrep и pkill в системах Solaris, HP-UX и Linux (но не в АЕХ) осуществляют поиск процессов, заданных именами (или другими атрибутами). Команда pgrep выводит идентификаторы процессов, удовлетворяющих заданному в командной строке критерию, а команда pkill посылает найденным процессам сигнал. Например, следующая команда посылает сигнал TERM всем процессам, выполняемым от имени пользователя ben. $ sudo pkill -u ben