17.15. Создание сервера-демона 635

> Смотри также-

Описание функции getsockname в perlfunc(l)\ документация по стандартным модулям Socket и IO::Socket; раздел «Sockets» врегИрс{\).

17.15. Создание сервера-демона

Проблема

Вы хотите, чтобы ваша программа работала в качестве демона.

Решение

Если вы - параноик с правами привилегированного пользователя, для начала вызовите chroot для безопасного каталога:

oh root ("/var/daemon )

or die "Couldnt chroot to /var/daemon: $!";

Вызовите fork и завершите родительский процесс.

$pid = fork; exit if Spid;

die "Couldnt fork; S!" unless defined($pid);

Разорвите связь с управляющим терминалом, с которого был запущен процесс, - при этом процесс перестает входить в группу процессов, к которой он принадлежал.

use POSIX;

POSIX;;setsid()

or die "Cant start a new session; $!";

Перехватывайте фатальные сигналы и устанавливайте флаг, означающий, что мы хотим корректно завершиться:

Stime to die = 0;

sub signal handler { $time to die = 1;

$SIG{INT} = SSIG{TERM} = $SIG{HUP} = \&signal handler; # Перехватить или игнорировать $SIG{PIPE}

Настоящий код сервера включается в цикл следующего вида:

until ($time to die) { «...

Комментарий

До появления стандарта POSIX у каждой операционной системы были свои средства, с помощью которых процесс говорил системе: «Я работаю в одиночку;

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

К числу этих функций принадлежит chroot, которая изменяет корневой каталог процесса (/). Например, после вызова chroot /var/daemon при попытке прочитать файл /etc/passwd процесс в действительности прочитает файл /var/ daemon/etc/passwd. Конечно, при вызове функции chroot необходимо скопировать все файлы, с которыми работает процесс, в новый каталог. Например, процессу может потребоваться файл /var/daemon/bin/csh. По соображениям безопасности вызов chroot разрешен только привилегированным пользователям. Он выполняется на серверах FTP при анонимной регистрации. На самом деле становиться демоном необязательно.

Операционная система иреднолагает, что родитель ожидает смерти потомка. Для нашего процесса-демона это не нужно, поэтому мы разрываем наследственные связи. Для этого программа вызывает fork и exit, чтобы потомок не был связан с процессом, запустившем родителя. Затем потомок закрывает все файловые манипуляторы, полученные от родителя (STDIN, STDERR и STDOUT), и вызывает POSIX setsid, чтобы обеспечить полное отсоединение от родительского терминала.

Все почти готово. Сигналы типа SIGINT не должны немедленно убивать наш процесс (поведение по умолчанию), поэтому мы перехватываем их с помощью %SIG и устанавливаем флаг заверщения Далее главная программа работает по принципу: «Пока не убили, что-то делаем».

Сигнал SIGPIPE - особый случай. Получить его нетрудно (достаточно записать что-нибудь в манипулятор, закрытый с другого конца), а по умолчанию он ведет себя довольно сурово (завершает процесс). Вероятно, его желательно либо проигнорировать ($SIG{PIPE} = IGNORE ), либо определить собственный обработчик сигнала и организовать его обработку.

> Смотри также-

Страницы руководства setsid(2) и chroot(i) вашей системы (если есть); описание функции chroot Bperlfunc{\).

17.16. Перезапуск сервера по требованию

Проблема

При получении сигнала HUP сервер должен нерезанускаться, но аналогии с metd или httpd.

Решение

Перехватите сигнал SIGHUP и нерезанустите свою программу:

$SELF = /usr/local/libexec/myd , # Моя программа @ARGS = qw(-l /var/log/myd -d), # Аргументы

$SIG{HUP} = \&phoenix,

17.17. Программа: backsniff 637

sub phoenix {

# Закрыть все соединения, убить потомков и

# приготовиться к корректному возрождению

exec($SELF, @ARGS) or die Couldn t restart $i\n ,

Комментарий

Внешне все выглядит просто («Получил сигнал HUP - перезапустись»), но на самом деле проблем хватает. Вы должны знать имя своей программы, а определить его непросто. Конечно, можно воспользоваться переменной $0 модуля FmdBin. Для нормальных программ этого достаточно, но важнейшие системные утилиты должны проявлять большую осторожность, поскольку правильность $0 не гарантирована. Имя программы и аргументы можно жестко закодировать в программе, как это сделано в нашем примере. Однако такое решение не всегда удобно, поэтому имя и аргументы можно читать из внешнего файла (зашишая подлинность его содержимого на уровне файловой системы).

Обработчик сигнала обязательно должен устанавливаться после определения $SELF и laARGS, в противном случае может возникнуть ситуация перехвата - SIGHUP потребует перезапуска, а вы не будете знать, что запускать. Это приведет к гибели вашей программы.

Некоторые серверы при получении SIGHUP не должны перезапускаться - они всего лишь заново читают свой конфигурационный файл:

$CDNFIG FILE = /usr/local/etc/myprog/server conf pi , $SIG{HUP} = \&read config sub read config { do $CONFIG FILE,

Некоторые умные серверы даже автоматически перезагружают свои конфигурационные файлы в случае их обновления. Вам даже не придется ни о чем сигнализировать.

> Смотри также-

Описание функции exec в рег1/ипс(\); рецепты 8.16-8.17; 16.15.

17.17. Программа: backsniff

Программа backsniff регистрирует попытки подключения к портам. Она использует модуль Sys::Syslog, а ему, в свою очередь, нужна библиотека syslog.ph, которая не обязательно присутствует в вашей системе. Попытка подключения регистрируется с параметрами LOG NOTICE и LOG DAEMON. Функция getsockname идентифицирует порт, к которому произошло подключение, а getpeername - компьютер, установивший соединение. Функция getservbyport преобразует локальный номер порта (например, 7) в название службы (например, echo ).