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

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

Мы называем эти программы даемонами. Даемоны это персонажи греческой мифологии; хорошие или плохие, они были спутниками человека и, вообще говоря, выполняли полезную работу для людей. Почти как веб- и почтовые серверы выполняют полезную работу сегодня. Это причина, по которой талисманом 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 сразу же остановит этот процесс4.

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

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

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