3.8 Демоны, сигналы, уничтожение процессов во FreeBSD


Если вы запускаете редактор, им можно легко управлять, открывать в нем файлы и т.д. Вы можете делать это, поскольку редактор предоставляет такие возможности и потому, что редактор присоединен к терминалу. Некоторые программы разработаны без поддержки интерфейса пользователя, поэтому они отсоединяются от терминала при первой возможности. Например, веб-сервер целый день отвечает на запросы из сети, и ему как правило не требуется ваше вмешательство. Программы, передающие почту от сервера к серверу -- другой пример приложений этого класса.

Мы называем эти программы демонами. Демоны это персонажи греческой мифологии; хорошие или плохие, они были спутниками человека и, вообще говоря, выполняли полезную работу для людей. Почти как веб- и почтовые серверы выполняют полезную работу сегодня. Это причина, по которой талисманом BSD долгое время является веселый демон в тапочках и с вилами.

Есть соглашение, по которому имя программы, которая обычно запускается как демон, заканчивается на ``d''. BIND это Berkeley Internet Name Daemon (выполняемая программа называется named), программа веб сервера Apache называется httpd, демон очереди печати это lpd и так далее. Это соглашение, а не жесткое правило; например, главный почтовый демон для Sendmail называется sendmail, а не maild, как вы могли бы предположить.

Иногда может потребоваться взаимодействие с процессом демона. Эти можно сделать с помощью сигналов, т.е. взаимодействовать с демонами (или с любыми запущенными процессами), посылая им сигнал. Есть множество различных сигналов -- некоторые из них имеют специальное значение, другие обрабатываются приложением, реакция которого на эти сигналы должна быть описана в документации. Вы можете посылать сигналы только тем процессам, владельцем которых являетесь. Если вы отправите сигнал какому-то другому процессу с помощью kill(1) или kill(2), доступ будет запрещен. Исключением из правил является пользователь root, который может отправлять сигналы любому процессу.

В некоторых случаях FreeBSD тоже посылает сигналы приложениям. Если приложение плохо написано и пробует обратиться к области памяти, к которой оно не должно обращаться, FreeBSD посылает процессу сигнал нарушение сегментации (SIGSEGV). Если приложение использует системный вызов alarm(3), чтобы получить уведомление по истечении определенного периода времени, будет отправлен сигнал Alarm (SIGALRM) и т.д.

Два сигнала могут быть использованы для завершения процесса, SIGTERM и SIGKILL. SIGTERM это корректный способ завершить процесс; процесс может поймать сигнал, определить, что его хотят завершить, закрыть любые файлы, которые он мог открыть, и закончить то, что он делал в момент перед закрытием. В некоторых случаях процесс может даже игнорировать SIGTERM, если выполняет задачу, которая не может быть прервана.

SIGKILL не может быть проигнорирован процессом. Этот сигнал говорит ``Меня не волнует что ты делаешь -- остановись немедленно''. Если вы посылаете процессу SIGKILL, FreeBSD сразу же остановит этот процесс[1].

Другие сигналы, которые возможно вам понадобятся, SIGHUP, SIGUSR1, и SIGUSR2. Это сигналы общего назначения, различные приложения могут по-разному реагировать на них.

Предположим, что вы изменили файл конфигурации веб сервера -- теперь нужно указать ему перечитать конфигурацию. Можно остановить и запустить httpd, но это приведет к кратковременной остановке сервера, которая может быть нежелательна. Большинство демонов написаны так, чтобы при получении сигнала SIGHUP перечитывать файлы конфигурации. Поэтому вместо уничтожения и запуска httpd можно послать сигнал SIGHUP. Поскольку нет стандартного способа реагирования на этот сигнал, различные демоны будут вести себя по разному; прочитайте документацию на демон по этому вопросу.

Сигналы посылаются с помощью команды kill(1), как показано в этом примере.

Отправка сигнала процессу

Этот пример показывает как послать сигнал inetd(8). Файл конфигурации inetd /etc/inetd.conf, inetd перечитает этот файл, если ему отправить сигнал SIGHUP.

Нужно определить PID процесса, которому вы хотите отправить сигнал. Сделайте это с помощью ps(1) и grep(1). Команда grep(1) используется для поиска по заданной строке в выходном потоке. Эта команда запускается под обычным пользователем, а inetd(8) под root, поэтому ps(1) должна быть запущена с параметром ax.
% ps -ax | grep inetd
198 ?? IWs 0:00.00 inetd -wW

Итак, PID inetd(8) 198. В некоторых случаях в выводе команды может также появиться grep inetd. Это из-за способа, которым ps(1) получает список запущенных процессов.

Используйте kill(1) для отправки сигнала. Поскольку inetd(8) запускается из под root, нужно сначала использовать su(1) для получения прав root.
% su
Password:
# /bin/kill -s HUP 198

Как и большинство команд UNIX®, kill(1) ничего не выведет, если отработает нормально. Если вы посылаете сигнал процессу, которым не владеете, на экране появится ``kill: PID: Operation not permitted''. При неправильно набранном PID вы или отправите сигнал другому процессу, что может привести к неприятностям, или, если повезет, сигнал будет отправлен на PID, который в данный момент не используется -- на экране появится ``kill: PID: No such process''.

Зачем использовать /bin/kill?: Во многих оболочках команда kill встроена; таким образом, оболочка вместо вызова /bin/kill сама посылает сигнал. Это может быть очень полезно, но в разных оболочках имя сигнала указывается по-разному. Чем пытаться выучить их все, гораздо проще использовать /bin/kill ... непосредственно.

Отправка других сигналов очень похожа, просто замените TERM или KILL в командной строке на имя другого сигнала.

Important: Уничтожение процессов наугад может быть плохой идеей. В частности, init(8), чей PID 1, имеет особое значение. Выполнение /bin/kill -s KILL 1 -- быстрый способ перегрузить систему. Всегда дважды проверяйте параметры запуска kill(1) перед тем, как нажать Enter.
Notes[1]
Не совсем верно -- есть несколько действий, которые не могут быть прерваны. Например, если процесс пытается прочитать файл на другом компьютере в сети, и другой компьютер по какой-то причине не отвечает (был выключен, или в сети произошла ошибка), процесс находится в так называемом ``непрерываемом состоянии''. В конце концов время ожидания закончится, обычно это происходит через две минуты. Как только время закончится, процесс будет уничтожен.

Обновлено: 12.03.2015