xinetd выполняет те же функции что и inetd: он запускает
процессы которые предоставляют различные сервисы интернет.
В отличие от сервисов которые стартуют во время инициализации системы
и пребывают в бездействии в ожидании запросов,xinetd представляет
собой только один процесс слушающий на всех портах сервисов перечисленных
в файле конфигурации xinetd.conf.
Когда приходит запрос xinetd запускает соответствующий сервер.
По причине такой работы xinetd
(так же как и inetd) называют еще супер-сервером.
Сервисы перечисленные в конфигурационном файле xinetd можно разделить
на две группы. Сервисы из первой группы называются multi-threaded
и на каждый новый запрос запускается новый серверный процесс. Для таких сервисов
xinetd продолжает слушать сеть на соответствующем порту ожидая новых
запросов и готовай породить новый процесс. В другую группу включаются
сервисы демоны которых в состоянии обрабатывать новые соединения. Такие сервисы
называются single-threaded
и xinetd прекращает обработку новых запросов до тех пор пока серверный
процесс не завершит свою работу. Сервисы в этой группе обычно datagram-based.
Итак, причиной существования супер-сервера является факт сохранения
системных ресурсов за счет не запуска множества серверных процессов
которые возможно будут бездействовать большую часть своей жизни.
Полностью соответствуя назначению запускать требуемые сервисы,
xinetd осуществляет так же функции контроля доступа и регистрации
событий. Кроме того xinetd не ограничен сервисами перечисленными
в файле /etc/services. Можно использовать xinetd для запуска
сервисов специального назначения.
ПАРАМЕТРЫ
-d
Активирует режим отладки. Этот параметр выводит много отладочной информации
и позволяет отладить работу xinetd.
-syslog syslog_facility
Этот параметр разрешает регистрацию событий используя syslog.
Сообщения производимые демоном xinetd регистрируются используя одну из
syslog facility. Следующие facility поддерживаются:
daemon,auth,user,local[0-7]
Эта опция не действует если активирован режим отладки, так как при отладке
все сообщения посылаются на консоль.
-filelog logfile
Производимые xinetd сообщения помещаются в указанный файл. Новые сообщения
всегда добавляются к существующим. Если файл не существует, то он создается. Опция
не действует в режиме отладки.
-f config_file
Определяет положение файла конфигурации xinetd. По умолчанию это -
/etc/xinetd.conf.
-pid
Идентификатор процесса (PID) выводится на устройство стандартной ошибки.
Не действует в режиме отладки.
-loop rate
Этот параметр устанавливает ограничение скорости запускания серверов,
указывается число запускаемых серверов в секунду. При превышении указанного
значения запуск новых процессов блокируется и сервис становится временно
недоступным. Значение этого параметра определяется производительностью
компьютера. По умолчанию - 10.
-reuse
Если указан этот параметр то, xinetd устанавливает
SO_REUSEADDR для сокета используемого сервисом.
Это позволяет использовать адрес даже если активны программы которые
уже его используют, это может случиться когда предыдущая копия
xinetd пытается запустить сервер который уже выполняется.
Параметр не эффективен с RPC сервисами.
-limit proc_limit
Этот параметр устанавливает предел на число одновременно выполняющихся процессов
запущенных демоном xinetd.
Использование параметра позволяет предотвратить переполнение таблицы процессов.
-logprocs limit
Параметр устанавливает максимальное значение одновременно выполняемых процессов
запущенных по запросу удаленного userid.
-shutdownprocs limit
Параметр устанавливает предельное число одновременно выполняющихся серверов
сервиса shutdown (concurrently running servers for service shutdown)
-cc interval
Параметр задает промежуток времени в секундах через который
xinetd производит периодическую проверку внутренней целостности.
Параметры syslog и filelog взаимно исключающие.
Если ничего не указано, то по умолчанию используется syslogdaemon facility.
Не путайте сообщения xinetd с сообщениями относящимися к функциям
регистрации событий. Последние журналируются только если это указано в файле
конфигурации.
УПРАВЛЕНИЕ XINETD
xinetd выполняет определенные действия при получении определенных
сигналов. Действия ассоциированные с соответствующими сигналами могут
быть переопределены путем редактирования config.h и последующей
компиляции.
SIGUSR1
вызывает мягкую переконфигурацию, это означает что xinetd перечитывает
файл конфигурации и подстраивается под изменения.
SIGUSR2
вызывает жесткую переконфигурацию, это значит то же самое что и мягкая
переконфигурация за исключением того что все серверы для сервисов которые
стали недоступны принудительно завершаются. Контроль доступа заново
выполняется для выполняющихся серверных процессов, путем проверки удаленного
хоста, времени доступа и количества выполняющихся серверов. Если
число выполняющихся процессов превышает заданное, произвольным образом
выбранные процессы убиваются что бы число оставшихся удовлетворяло
поставленному условию. Так же если флаг INTERCEPT
был сброшен или установлен, все серверы обеспечивающие этот сервис завершаются.
Все это выполняется для того что бы после жесткой реконфигурации не
осталось не одного работающего процесса обрабатывающего запросы с адресов
не соответствующих критериям контроля доступа.
.
SIGQUIT
приводит к завершению программы.
SIGTERM
завершает все выполняющиеся серверы перед завершением xinetd.
SIGHUP
приводит к генерации дампа внутреннего состояния (по умолчанию файл дампа
/tmp/xinetd.dump; что бы сменить отредактируйте
config.h и перекомпилируйте).
SIGIOT
вызывает проверку внутренней целостности что бы проверить что структуры
данных используемые программой не повреждены. После завершения проверки
xinetd генерирует сообщение о результате проверки.
При реконфигурации лог-файлы закрываются и вновь открываются. Это
позволяет удалять старые логи.
Panos Tsirigotis, CS Dept, University of Colorado, Boulder
ПРОИЗНОШЕНИЕ
zy-net-d
зи-нет-ди
ПРИМЕЧАНИЕ
Я несколько не согласен с терминологией авторов относительно
"multi-threaded" и "single-threaded", в текстах
прочитанных мною ранее например объяснения разницы архитектуры Apache
и M$ IIS или Oracle и M$ SQL а также различных реализаций InterBase V6
то что авторы называют "multi-threaded" принято называть "классической
архитектурой" (Classic) - на каждый запрос свой процесс, а для того что
здесь названо "single-threaded"
используется термин "многопоточный" (multi-threaded - вот оно,
в точности наоборот :) или "суперсерверная архитектура", то есть в рамках
одного процесса несколько потоков(нитей). В данном документе
я решил при переводе оставить терминологию оригинального текста.
