xinetd не запустится

Когда сервис не запускает и не дает сообщение об ошибке, вероятно, стоит попытаться запустить сервис вручную. Первое, что нужно сделать состоит в том, чтобы работать:

# bash -x /etc/init.d/xinetd start

Это покажет Вам все команды, которые выполняются для запуска сервиса. Это могло бы дать Вам ключ к разгадке относительно того, почему он не запускается. Если это не делает затем, можно найти, что заключительная команда раньше запускала демона и выполняла это вручную. Это обычно оказывается полезным. Если это все еще не помогает, необходимо выполнить команду под strace.

(Примечание: я не использовал CentOS в долгое время, таким образом, пути и вещи не могли бы быть корректными. Я не думаю, что это использует выскочку все же, но если это делает, посмотрите в/etc/event.d/xinetd или/etc/init/xinetd.conf, и это должно иметь команду для выполнения вручную.)

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

/usr/sbin/xinetd -f /etc/xinetd.conf -d

На моем хинду поле, когда у меня не будет сервисов определенными, вышеупомянутая команда выйдет после ниже отладочной информации

09/10/26@21:26:05: DEBUG: 23117 {cnf_start_services} mask_max = 0, services_started = 0
09/10/26@21:26:05: CRITICAL: 23117 {init_services} no services. Exiting...

С включенным сервисом (chargen в этом случае, в/etc/xinetd.d/chargen-stream изменении строка 'отключают = yes' для 'отключения = не') выполнение вышеупомянутой команды производит следующий вывод, и xinetd не выходит до Ctrl-c хита.

09/10/26@21:41:00: DEBUG: 23261 {cnf_start_services} Started service: chargen-stream
09/10/26@21:41:00: DEBUG: 23261 {cnf_start_services} mask_max = 6, services_started = 1
09/10/26@21:41:00: NOTICE: 23261 {main} xinetd Version 2.3.14 started with libwrap loadavg options compiled in.
09/10/26@21:41:00: NOTICE: 23261 {main} Started working: 1 available service
09/10/26@21:41:00: DEBUG: 23261 {main_loop} active_services = 1

Как примечание стороны, если Вы запускаете init скрипт с chargen, включенным затем, необходимо смочь использовать netstat, чтобы видеть, что xinetd слушает на chargen порте путем выполнения следующей команды:

netstat -tap | grep xinetd

Вывод должен выглядеть примерно так:

tcp    0   0 *:chargen        *:*       LISTEN     23439/xinetd

Мне обычно, который является признаком, что существует что-то не так со сценарием для управления сервисом, т.е. переменная, которая имеет двоичный файл, не указывает на правильное местоположение.

Можете Вы кошка/etc/init.d/xinetd и позволять нам видеть то, что она говорит?

xinetd является странным зверем. Как упомянутый Zoredache, это не запустится, если это не будет иметь что-то, чтобы сделать. Вы заявляете свою попытку получить выполнение tftpd, которое пробегает xinetd.

По умолчанию, когда tftpd-сервер установлен, он помещает файл, названный tftp в/etc/xinetd.d. Каталог xinetd заглядывает, когда он начинает видеть, имеет ли он что-нибудь, чтобы сделать. В/etc/xinetd.d/tftp файле посмотрите существует строка, которая говорит, "отключают = да". Если существует один, который является, вероятно, Вашей проблемой. xinetd запускает, читает файл, но говорится, что tftp отключен. Таким образом ни с чем, чтобы сделать это выходит.

Для решения этой проблемы (если это - действительно проблема) отредактируйте/etc/xinetd.d/tftp файл и изменитесь, "отключают = да" для "отключения = не". Теперь попытайтесь перезапустить xinetd.

Вещи пары проверить:

Ваш /etc/xinetd.conf должен выглядеть примерно так:

defaults
{
    instances               = 60
    log_type                = SYSLOG authpriv
    log_on_success          = HOST PID
    log_on_failure          = HOST
    cps                     = 25 30
}
includedir /etc/xinetd.d

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

Начиная с 'отключают =, бит ye был уже покрыт, это не проблема.

Можно отредактировать/etc/sysconfig/xinetd для передачи этих аргументов xinetd:

-d -dontfork - это включит режим отладки и заставит xinetd оставаться "живым" даже при том, что ничто не работает, возможно, он даст Вам больше понимания.

Имел подобную проблему на работе CentOS x64 OpenVZ с veth.

Прокомментированный эта строка: ["$ {СЕТИ}" = "да"] || выходят 0

Просто поместите # перед этой строкой в/etc/init.d/xinetd, и это работает на меня теперь. Я думаю, что это - проблема с сетевой проверкой при использовании veth интерфейса.

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

chkconfig --list xinetd

Необходимо видеть:

xinetd          0:off   1:off   2:off   3:on    4:on    5:on    6:off

Если все уровни выключены, или если xinetd не регистрируется как услуга:

chkconfig --add xinetd
chkconfig --level 345 xinetd on

В RHEL СЕТЕВАЯ переменная оценена в/etc/sysconfig/network, который получен vi init сценарий. Ваша переменная, вероятно, установлена на NETWORKING=no или не набор вообще. Если Вы устанавливаете это значение, Вы должны быть все установлены