В этом разделе поэтапно рассмотрим процесс обработки сигналов (таких как прерывания), поступающих из внешнего мира, а также ошибок программы. Ошибки программ возникают в основном из-за непра-
вильных обращений к памяти, при выполнении специфических инст рукций или из-за операций с плавающей точкой. Наиболее распространенные сигналы, поступающие из внешнего мира: прерывание (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 года, представляет несколько отличающийся от привычного проект реализации исправления орфографических ошибок в контексте почтовой программы.
Сигналы — программные прерывания. Они используются для связи между процессами в UNIX и UNIX-подобных операционных систем, таких как Linux, Mac OS.
Сигналы использовались еще с Bell Labs UNIX в 1970 и сегодня официально определено стандартом POSIX. Когда сигнал поступает на процесс, операционная система прерывает нормальный поток выполнения процесса и обеспечивает уведомление.
Не имеет значения, какую операционную систему вы используете, вы несомненно столкнетесь с тем что ваши приложения, блокируются и отказаться работать должным образом. В Unix, Linux, есть команда «kill», которую вы можете использовать, чтобы прекратить процесс немедленно, но и не только это, но об этом немного позже я расскажу. В этой статье «Команда kill в Unix/Linux» я расскажу и покажу на готовых примерах различные команды утилиты kill.
Команды kill и сигналы
Когда вы выполняете команду «kill», вы на самом деле посылает е сигнал к системе и даете указание расторгнуть работу некорректной роботы приложения. Существует в общей сложности 60 сигналов, которые можно использовать, но все, что вы действительно должны знать, SIGTERM (15) и SIGKILL (9).
Вы можете просмотреть все сигналы с помощью команды:
# kill -l
На моей MacOS:
Я постараюсь рассказать о всех сигналах, но для самого начала поговорим только о самых важных и часто использующихся.
Основные сигналы
Следующие сигналы являются частью стандарта POSIX. Каждый сигнал макрос, определенный в
SIGTERM – Этот сигнал запрашивает остановку процесса который работает. Этот сигнал может быть проигнорирован.Процессу дается время, чтобы хорошо выключился. Когда программа хорошо выключается, это означает, что ей дано время, чтобы спасти его прогресс и освободить ресурсы. Другими словами, он не «forced» прекращение работы процесса.
SIGKILL – сигнал SIGKILL заставляет процесс прекратить выполнение своей работы немедленно. Программа не может игнорировать этот сигнал. Несохраненный прогресс будет потерян.
Синтаксис для «kill».
Синтаксис команды такой:
# kill PID(s)
# kill [-s] [-l] %pid
Сигнал по умолчанию (если он не указан) является SIGTERM. Когда данный сигнал не помогает и не работает, вы можете использовать следующие опции для «kill» чтобы завершить процесс принудительно:
# kill SIGKILL PID
# kill -9 PID
где «-9» — это флаг относится к сигналу SIGKILL.
Если вы не знаете какой нужно использовать PID приложения которого следует избавиться, то запустите команду:
$ ps -aux
А если знаете конкретное приложение (например apache), то можно отсеять ненужное и вывести все процессы по данной службе:
$ ps -aux | grep apache
И это отобразит все запущенные приложения вместе с его PID-ом(ами).
Например, чтобы убить приложение, я выполните следующую команду:
# kill -9 3629
Стоит также отметить, что вы можете использовать несколько процессов одновременно чтобы их можно было » убить»:
# kill -9 PID1 PID2 PID 3
Перезагурзить конфигурационные файлы или перезапуск утилит:
# kill -1 number_of_PID
Особенно полезными сигналы включают HUP, INT, kill, STOP, CONT, и 0.
Варианты таковы:
-s signal_name
Символическое имя сигнала, задающее сигнал для отправки сигнала не по умолчанию.
-l
Если операнд не указан, то показать имена сигналов; В противном случае, написать название сигнала, соответствующего exit_status.
-signal_name
Символическое имя сигнала, задающее сигнал для отправки в TERM по умолчанию.
-signal_number
Неотрицательное десятичное целое, задающее сигнал для отправки в TERM по умолчанию.
Следующие PID-ы, имеют особое значение:
-1
Если суперпользователь, то транслирует сигнал всем процессам; в противном случае вещает на все процессыbelong-
ing для пользователя.
Некоторые из наиболее часто используемых сигналов:
- 1 HUP (hang up) — повесить.
- 2 INT (interrupt) — прерывание.
- 3 QUIT (quit) — выход.
- 6 ABRT (abort) — прерывания.
- 9 KILL (non-catchable, non-ignorable kill)
- 14 ALRM (alarm clock) — будильник.
- 15 TERM (software termination signal) — Программное обеспечение для прекращения сигнала.
PKill
Команда «pkill» позволяет использовать расширенные шаблоны регулярных выражений и других критериев соответствия. Вместо того чтобы использовать PID, теперь вы можете убить приложение, введя имя процесса. Например, чтобы убитьбраузер Firefox , просто запустите команду:
# pkill Firefox
Так как он соответствует шаблону регулярного выражения, вы также можете ввести часть имени процесса, например:
# pkill fire
Чтобы избежать «убийства» неправильных процессов, вы можете сделать «pgrep -l [имя_процесса]» в список подходящих процессов.
Pkill команда имеет гораздо больше вариантов, например если указать опцию «-u», то она позволит вам указать имя пользователя или ID. В этом примере мы посылаем сигнал TERM всем процессам, принадлежащие пользователю ‘nobody’:
# pkill -u nobody
Killall
Killall использует имя процесса, а вместо PID, и он «убивает» все экземпляры процесса с тем же именем. Например, если вы используете несколько экземпляров браузера Firefox, вы можете убить их всех с помощью команды:
# killall firefox
В Gnome, вы можете перезапустить Nautilus с помощью команды:
# killall nautilus
xkill
Xkill является графическим способом «убить» приложение. При вводе «XKill» в терминале, курсор мыши будет немедленно стать «крест». Все, что вам нужно сделать, это нажать «крест» на провинившихся приложение и он убьет приложение мгновенно. Если вы заинтересованы, вы можете добавить сочетание клавиш для включения функции XKill.
Еще сигналы которые используются
SIGABRT
Этот сигнал посылает сигнал процессу, чтобы прервать операцию. ABRT как правило, направлен на сам процесс, когда он вызывает функцию abort() языка программирования С, чтобы сигнализировать аварийное завершение, но он может быть направлен из любого процесса, как и любой другой сигнал.
SIGALRM, SIGVTALRM и SIGPROF
ALRM, VTALRM и / или сигнал PROF отправляется процессу, когда лимит времени, указанный при вызове функции сигнализации (например, setitimer) истекает.
ALRM
Посылается, когда настоящее время или часы с течением времени.
VTALRM
Посылается, когда процессорное время, используемое в процессе истечет.
PROF
Посылается, когда процессорное время, используемое процессом и системы от имени процесса истекает.
SIGBUS
BUS сигнал посылает процессу, когда это приводит к ошибке шины. Условия, которые приводят к данному сигналу, например, неправильное выравнивание доступа к памяти или отсутствие физического адреса.
SIGCHLD
Сигнал CHLD отправляет процессу, когда дочерний процесс завершается, прерывается или возобновляется после прерывания. Один из распространенного использование сигнала — это дать сигнал ОС на очистку ресурсов, которые используются в процессе дочернего процесса после его окончания без явного системного вызова.
SIGCONT
Сигнал CONT инструктирует операционную систему, и дает сигнал перезапустить процесс который ранее был приостановлен в режиме СТОП или сигнала TSTP. Одной из важных особенностей этого сигнала является контроль работы в оболочке Unix.
SIGFPE
Сигнал FPE посылает процессу, когда он выполняет ошибочное, арифметические срабатывания, например, такие как деление на ноль.
SIGHUP
Сигнал HUP посылает процессу, когда его управляющий терминал закрыт. Первоначально он был разработан, чтобы уведомить процесс после последовательного падения линии (HUP ответственный за «зависания»). В современных системах, этот сигнал обычно означает, что контроль псевдо или виртуальным терминалом был закрыт.
SIGILL
ILL сигнал, посылаемый процессу при попытке выполнить вредоносные, неизвестные или привилегированные команды (инструкции).
SIGINT
Сигнал INT посылает процессу от управляющего терминала, когда пользователь желает прервать процесс. Это как правило, инициируется нажатием Control-C, но на некоторых системах, «delete» или «break».
SIGKILL
Сигнал KILL посылает процессу чтобы он немедленно прекратил работу. В отличие от SIGTERM и SIGINT этот сигнал не может быть захвачен или проигнорирован и принимающий процесс не может выполнить какие-либо очистку после получения этого сигнала.
SIGPIPE
Сигнал PIPE посылается процессу, когда он пытается записать в трубе без процесса, подключенного к другому концу.
SIGQUIT
QUIT сигнал посылается процессу от его управляющего терминала, когда пользователь запрашивает процесс выполнения дампа.
SIGSEGV
Сигнал SEGV отправляется в процесс, когда он делает недопустимую ссылку виртуальной памяти или сбой сегментации, то есть когда он выполняет нарушение сегментации.
SIGSTOP
STOP сигнал указывает ОС, чтобы остановить процесс для последующего возобновления.
SIGTERM
Сигнал TERM посылается в процесс чтобы запросить о его прекращении. В отличие от сигнала «kill», он может быть и интерпретируемым или игнорируемым в процессе. Это позволяет процессу выполнять «nice» выполнение для прекращения высвобождения ресурсов и сохранения состояния в случае необходимости. Следует отметить, что SIGINT почти идентичен SIGTERM.
SIGTSTP
Сигнал TSTP посылается в процесс его управляющего терминала и говорит ему, что нужно временно приостановить. Это обычно инициируется пользователем нажатием Control-Z. В отличие от SIGSTOP, этот процесс может зарегистрировать обработчик сигнала или чтобы игнорировать сигнал.
SIGTTIN и SIGTTOU
В TTIN и TTOU сигналы посылаются процессу, когда он пытается прочитать или записать соответственно с (tty) терминала на заднем плане. Как правило, этот сигнал может быть получен только с помощью процессов находящихся под контролем рабочей панели; демоны не имеют управляющие терминалы и никогда не должны получать этот сигнал.
SIGUSR1 и SIGUSR2
Сигналы USR1 и USR2 отправляются процессу и указывают определенные пользователем условия.
SIGPOLL
Сигнал POLL отправляется в процессе, когда происходит асинхронное событие ввода / вывода.
SIGSYS
Сигнал SYS отправляется в процессе, когда он пропускает плохой аргумент для системного вызова.
SIGTRAP
TRAP сигнал посылает процессу когда возникает состояние что отладчик просил быть информированным — Например, когда конкретная функция выполняется или когда меняется определенное значение переменной.
SIGURG
Сигнал URG отправляется процессу, когда socket имеет срочные или вне диапазона данных, доступных для чтения.
SIGXCPU
Сигнал XCPU отправляется в процессе, когда он использует центральный процессор в течение времени превышающего определенное заданное значение, установленным пользователем. Прибытие сигнала XCPU обеспечивает процессу быстро сохранить все промежуточные результаты и завершиться хорошо, прежде чем он завершиться операционной системы с помощью сигнала SIGKILL.
SIGXFSZ
Сигнал XFSZ отправляется в процессе, когда файл вырастает (превышает заданное значение), чем максимально допустимое значение.
SIGRTMIN to SIGRTMAX
Сигналы RTMIN — RTMAX предназначены для использования в пользовательских целей. Они сигналы реального времени.
Разные сигналы
Следующие сигналы не стандартизированы POSIX, но иногда используются на некоторых системах.
SIGEMT
Сигнал ЕМТ отправляется в процессе, когда происходит прерывание эмулятора.
SIGINFO
Сигнал INFO отправляется в процессе, когда запрос статуса получен от управляющего терминала.
SIGPWR
Сигнал PWR отправляется в процессе, когда система испытывает сбой питания.
SIGLOST
LOST сигнал посылается к процессу, когда «file lock» теряется.
SIGWINCH
Сигнал WINCH отправляется в процессе, когда его управляющий терминал меняет свой размер.
Отправка сигналов с клавиатуры
Сигналы могут быть отправлены с клавиатуры. Несколько стандартных значений по умолчанию перечислены ниже. По умолчанию сочетания клавиш для отправки сигналов прерывания может быть определен с помощью команды stty.
CTRL-C
Отправить SIGINT (прерывание). По умолчанию это вызывает процесс прекращается.
CTRL-Z
Отправить SIGTSTP (Suspend). По умолчанию это вызывает процесс приостановить все операции.
CTRL-\
Отправить SIGQUIT (Quit). По умолчанию это вызывает процесс прекратить немедленно и сбросить ядро.
CTRL-T
Отправить SIGINFO (INFO). По умолчанию это заставляет операционную систему отображать информацию о команде. Не поддерживается на всех системах.
вывод
Когда приложения ведут себя неправильно и вызвают к зависанию системы, это очень заманчиво, чтобы перезагрузить компьютер и начать сеанс снова и снова. С помощью этих команд «kill», вы сможете лучше управлять плохим поведением приложений которые вызывают или могут вызвать крах системы. На этом, я завершаю данную тему «Команда kill в Unix/Linux».
Рассмотрим теперь другую программу – 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 |
|
|
За этими сигналами не зарезенвированы никакие системные назначения. Процессы могут посылать эти сигналы друг другу и интерпретировать их по своему усмотрению. |
|
Более подробно про типы сигналов см. в описании функции
Многие программы 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
