Читать онлайн «UNIX: разработка сетевых приложений». Страница 104

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

Существует несколько способов запустить демон:

1. Во время запуска системы многие демоны запускаются сценариями инициализации системы. Эти сценарии часто находятся в каталоге /etc  или в каталоге, имя которого начинается с /etc/rc, но их расположение и содержание зависят от реализации. Такие демоны запускаются с правами привилегированного пользователя.

Некоторые сетевые серверы часто запускаются из сценариев инициализации: суперсервер inetd (следующий пункт, который мы рассмотрим), веб-сервер и почтовый сервер (обычно это программа sendmail). Демон syslogd, обсуждаемый в разделе 13.2, тоже обычно запускается одним из этих сценариев.

2. Многие сетевые серверы запускаются суперсервером inetd, который мы опишем далее в этой главе. Сам inetd запускается в одном из сценариев на этапе 1. Суперсервер inetd прослушивает сетевые порты (Telnet, FTP и т.д.), и когда приходит запрос, активизирует требуемый сервер (сервер Telnet, сервер FTP и т.д.).

3. За периодические процессы в системе отвечает демон cron, и программы, которые он активизирует, выполняются как демоны. Сам демон cron запускается на этапе 1 во время загрузки системы.

4. Если программа должна быть выполнена однократно в определенный момент времени в будущем, применяется команда at. Демон cron обычно инициирует эти программы, когда приходит время их выполнения, поэтому они выполняются как демоны.

5. Демоны можно запускать с пользовательских терминалов, как в основном, так и в фоновом режимах. Это часто осуществляется при тестировании демона или перезапуске демона, завершенного по некоей причине.

Поскольку у демона нет управляющего терминала, ему необходимы средства для вывода сообщений о некоторых событиях — это могут быть обычные информационные сообщения или экстренные сообщения об аварийных ситуациях, которые должен обрабатывать администратор. Использование функции syslog — стандартный способ вывода таких сообщений. Эта функция посылает сообщения демону syslogd.

Системы Unix обычно запускают демон syslogd в одном из сценариев инициализации системы, и он функционирует, пока система работает. Реализации syslogd, происходящие от Беркли, выполняют при запуске следующие действия:

1. Считывается файл конфигурации, обычно /etc/syslog.conf, в котором указано, что делать с каждым типом сообщений, получаемых демоном. Эти сообщения могут добавляться в файл (особой разновидностью такого файла является /dev/console, который записывает сообщение на консоль), передаваться определенному пользователю (если этот пользователь вошел в систему) или передаваться демону syslogd на другом узле.

2. Создается доменный сокет Unix и связывается с полным именем /var/run/log (в некоторых системах /dev/log).

3. Создается сокет UDP и связывается с портом 514 (служба syslog).

4. Открывается файл (устройство) /dev/klog. Любые сообщения об ошибках внутри ядра появляются как входные данные на этом устройстве.

Демон syslogd выполняется в бесконечном цикле, в котором вызывается функция select, ожидающая, когда один из трех его дескрипторов (из п. 2, 3 и 4) станет готов для чтения. Этот демон считывает сообщение и выполняет то, что предписывает делать с этим сообщением файл конфигурации. Если демон получает сигнал SIGHUP, он заново считывает файл конфигурации.

ПРИМЕЧАНИЕ

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

Между реализациями демона syslogd существуют различия. Например, доменные сокеты Unix используются Беркли-реализациями, а реализации System V используют потоковый драйвер (streams log driver). Различные реализации, происходящие от Беркли, используют для доменных сокетов Unix различные полные имена. Мы можем игнорировать все эти тонкости, если используем функцию syslog.

Мы можем отправлять сообщения о событиях для записи в журнал (log messages) демону syslogd из наших демонов, создав дейтаграммный доменный сокет Unix и указывая при отправке полное имя, с которым связан демон, но более простым интерфейсом является функция syslog, которую мы описываем в следующем разделе. В качестве альтернативы мы можем создать сокет UDP и отправлять наши сообщения на адрес закольцовки и порт 514.

Поскольку у демона нет управляющего терминала, он не может просто вызвать функцию fprintf для вывода в стандартный поток сообщений об ошибках (stderr). Обычная техника записи в журнал сообщений для демона — это вызов функции syslog.

#include <syslog.h>

void syslog(int priority, const char *message, ...);

Хотя эта функция изначально разрабатывалась для BSD, в настоящее время она предоставляется большинством производителей систем Unix. Описание syslog в POSIX соответствует тому, что мы пишем здесь. RFC 3164 содержит документацию, касающуюся протокола syslog BSD.

Аргумент priority — это комбинация аргументов level и facility, которые мы показываем в табл. 13.1 и 13.2. Дополнительные сведения об этом аргументе можно найти в RFC 3164. Аргумент message аналогичен строке формата функции printf с добавлением спецификации %m, которая заменяется сообщением об ошибке, соответствующим текущему значению переменной errno. Символ перевода строки может появиться в конце строки message, но он не является обязательным.

Сообщения для журнала имеют значение level (уровень) от 0 до 7, что мы показываем в табл. 13.1. Это упорядоченные значения. Если отправитель не задает значение level, используется значение по умолчанию LOG_NOTICE.

Таблица 13.1. Аргумент level журнальных сообщений

Level Значение Описание LOG_EMERG 0 Система не может функционировать, экстренная ситуация (наивысший приоритет) LOG_ALERT 1 Следует немедленно принять меры, срочная ситуация LOG_CRIT 2 Критическая ситуация LOG_ERR 3 Состояние ошибки LOG_WARNING 4 Предупреждение LOG_NOTICE 5 Необычное, хотя и не ошибочное состояние (значение аргумента level по умолчанию) LOG_INFO 6 Информационное сообщение LOG_DEBUG 7 Отладочные сообщения (низший приоритет)

Сообщения также содержат аргумент facility для идентификации типа процесса, посылающего сообщение. Мы показываем его различные значения в табл. 13.2. Если не задано значение аргумента facility, используется его значение по умолчанию — LOG_USER.

Таблица 13.2. Аргумент facility журнальных сообщений

facility Описание LOG_AUTH Сообщения no безопасности/авторизации LOG_AUTHPRIV Сообщения по безопасности/авторизации (частные) LOG_CRON Демон cron LOG_DAEMON Системные демоны LOG_FTP Демон FTP LOG_KERN Сообщения ядра LOG_LOCAL0 Локальное использование LOG_LOCAL1 Локальное использование LOG_LOCAL2 Локальное использование LOG_LOCAL3 Локальное использование LOG_LOCAL4 Локальное использование LOG_LOCAL5 Локальное использование LOG_LOCAL6 Локальное использование LOG_LOCAL7 Локальное использование LOG_LPR Демон принтера LOG_MAIL Почтовая система LOG_NEWS Система телеконференций LOG_SYSLOG Внутренние сообщения системы syslog LOG_USER Сообщения пользовательского уровня (значение аргумента facility по умолчанию) LOG_UUCP Система UUCP

Например, демон может сделать следующий вызов, когда вызов функции rename неожиданно оказывается неудачным: