Читаем Linux API. Исчерпывающее руководство полностью

switch (fork()) { /* Превращение в фоновый процесс */

case –1: return –1;

case 0: break; /* Потомок проходит этот этап… */

default: _exit(EXIT_SUCCESS); /*…а родитель завершается */

}

if (setsid() == –1) /* Процесс становится лидером новой сессии */

return –1;

switch (fork()) { /* Делаем так, чтобы процесс

не стал лидером сессии */

case –1: return –1;

case 0: break;

default: _exit(EXIT_SUCCESS);

}

if (!(flags & BD_NO_UMASK0))

umask(0); /* Сбрасываем маску режима создания файлов */

if (!(flags & BD_NO_CHDIR))

chdir("/"); /* Переходим в корневой каталог */

if (!(flags & BD_NO_CLOSE_FILES)) { /* Закрываем все открытые файлы */

maxfd = sysconf(_SC_OPEN_MAX);

if (maxfd == –1) /* Ограничение не определено… */

maxfd = BD_MAX_CLOSE; /*…поэтому устанавливаем его наугад */

for (fd = 0; fd < maxfd; fd++)

close(fd);

}

if (!(flags & BD_NO_REOPEN_STD_FDS)) {

close(STDIN_FILENO); /* Перенаправляем стандартные потоки

данных в /dev/null */

fd = open("/dev/null", O_RDWR);

if (fd!= STDIN_FILENO) /* Значение 'fd' должно быть больше 0 */

return –1;

if (dup2(STDIN_FILENO, STDOUT_FILENO)!= STDOUT_FILENO)

return –1;

if (dup2(STDIN_FILENO, STDERR_FILENO)!= STDERR_FILENO)

return –1;

}

return 0;

}

daemons/become_daemon.c

Написав программу, которая вызывает функцию becomeDaemon(0), и затем на какое-то время останавливается, мы сможем рассмотреть некоторые атрибуты итогового процесса, воспользовавшись командой ps(1):

$ ./test_become_daemon

$ ps — C test_become_daemon — o “pid ppid pgid sid tty command”

PID PPID PGID SID TT COMMAND

24731 1 24730 24730?./test_become_daemon

Мы не приводим здесь исходный код программы daemons/test_become_daemon.c, так как он достаточно тривиален; вы можете найти его в архиве с исходными файлами, который прилагается к этой книге.

В выводе команды ps знак? в столбце TT указывает на то, что процесс не привязан к контролирующему терминалу. Из того факта, что идентификаторы процесса и сессии (SID) не совпадают, можно сделать вывод, что процесс не является лидером сессии и не сможет установить соединение с контролирующим терминалом при открытии соответствующего устройства. Именно так и должен вести себя демон.

37.3. Рекомендации по написанию демонов

Как уже отмечалось выше, процесс-демон обычно завершается во время выключения системы. Для многих стандартных демонов предусмотрены специальные скрипты, которые выполняются, когда система завершает работу. Остальные демоны просто получают сигнал SIGTERM, который при выключении компьютера отправляется процессом init всем своим потомкам. По умолчанию этот сигнал приводит к завершению процесса. Если демону перед этим необходимо освободить какие-либо ресурсы, он должен делать это в обработчике данного сигнала. Эту процедуру следует выполнять как можно быстрее, поскольку через 5 секунд после SIGTERM процесс init отправляет сигнал SIGKILL (это вовсе не означает, что у демона есть 5 секунд процессорного времени на освобождение ресурсов; init шлет эти сигналы всем процессам в системе одновременно, поэтому процедуру очистки в этот момент может выполнять каждый из них).

Так как демоны имеют длинный жизненный цикл, нам следует особенно тщательно следить не только за потенциальными утечками памяти (см. подраздел 7.1.3), но и за файловыми дескрипторами (когда приложению не удается закрыть все файловые дескрипторы, которые оно открыло). Для временного исправления подобных ошибок демон приходится перезапускать заново.

Часто демону необходимо убедиться в том, что только один его экземпляр активен в любой заданный момент времени. Например, запуск двух копий демона cron для выполнения одних и тех же заданий не имел бы никакого смысла. Методики, позволяющие этого достичь, будут рассмотрены в разделе 51.6.

37.4. Использование сигнала SIGHUP для повторной инициализации демона

Из того факта, что демоны должны выполняться непрерывно, вытекает две проблемы.

• Обычно при запуске демон считывает параметры из соответствующего конфигурационного файла. Но иногда возникает необходимость изменить эти параметры на лету, без остановки или перезапуска самого демона.

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