4.8. Даемоны, сигналы, уничтожение процессов
Пред. | Глава 4. Основы UNIX | След.

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

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

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

Есть соглашение, по которому имя программы, которая обычно запускается как даемон, заканчивается на «d». BIND это Berkeley Internet Name Domain, а выполняемая программа называется `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 сразу же остановит этот процесс[4].

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

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

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

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

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

1. Нужно определить 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) получает список запущенных процессов.

2. Используйте 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` в командной строке на имя другого сигнала.

### Важно:

Уничтожение процессов наугад может быть плохой идеей. В частности, init(8), чей PID 1, имеет особое значение. Выполнение `/bin/kill -s KILL 1` — быстрый способ перегрузить систему. Всегда дважды проверяйте параметры запуска kill(1) перед тем, как нажать Enter.

[4] Не совсем верно — есть несколько действий, которые не могут быть прерваны. Например, если процесс пытается прочитать файл на другом компьютере в сети, и другой компьютер по какой-то причине не отвечает (был выключен, или в сети произошла ошибка), процесс находится в так называемом «непрерываемом состоянии». В конце концов время ожидания закончится, обычно это происходит через две минуты. Как только время закончится, процесс будет уничтожен.

Пред. | Наверх | След.
4.7. Процессы | Начало | 4.9. Интерпретатор команд

Этот, и другие документы, могут быть скачаны с http://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите в рассылку <doc@FreeBSD.org>.