и 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 взаимно исключающие.
Если ничего не указано, то по умолчанию используется syslog
daemon facility.
Не путайте сообщения xinetd с сообщениями относящимися к функциям
регистрации событий. Последние журналируются только если это указано в файле
конфигурации.
УПРАВЛЕНИЕ XINETD
xinetd выполняет определенные действия при получении определенных
сигналов. Действия ассоциированные с соответствующими сигналами могут
быть переопределены путем редактирования config.h и последующей
компиляции.
- SIGUSR1
-
вызывает мягкую переконфигурацию, это означает что xinetd перечитывает
файл конфигурации и подстраивается под изменения.
- SIGUSR2
-
вызывает жесткую переконфигурацию, это значит то же самое что и мягкая
переконфигурация за исключением того что все серверы для сервисов которые
стали недоступны принудительно завершаются. Контроль доступа заново
выполняется для выполняющихся серверных процессов, путем проверки удаленного
хоста, времени доступа и количества выполняющихся серверов. Если
число выполняющихся процессов превышает заданное, произвольным образом
выбранные процессы убиваются что бы число оставшихся удовлетворяло
поставленному условию. Так же если флаг INTERCEPT
был сброшен или установлен, все серверы обеспечивающие этот сервис завершаются.
Все это выполняется для того что бы после жесткой реконфигурации не
осталось не одного работающего процесса обрабатывающего запросы с адресов
не соответствующих критериям контроля доступа.
.
- SIGQUIT
-
приводит к завершению программы.
- SIGTERM
-
завершает все выполняющиеся серверы перед завершением xinetd.
- SIGHUP
-
приводит к генерации дампа внутреннего состояния (по умолчанию файл дампа
/tmp/xinetd.dump; что бы сменить отредактируйте
config.h и перекомпилируйте).
- SIGIOT
-
вызывает проверку внутренней целостности что бы проверить что структуры
данных используемые программой не повреждены. После завершения проверки
xinetd генерирует сообщение о результате проверки.
При реконфигурации лог-файлы закрываются и вновь открываются. Это
позволяет удалять старые логи.
ФАЙЛЫ
- /etc/xinetd.conf
-
стандартный конфигурационный файл
- /var/run/xinetd.dump
-
стандартный файл дампа
СМОТРИТЕ ДОПОЛНИТЕЛЬНО
inetd(8),
xinetd.conf(5),
xinetd.log(5)
АВТОР
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 - вот оно,
в точности наоборот :) или "суперсерверная архитектура", то есть в рамках
одного процесса несколько потоков(нитей). В данном документе
я решил при переводе оставить терминологию оригинального текста.