systemd, запуск демонов после поднятия сети

ProFfeSsoRr	# 9 лет, 10 месяцев назад
Темы: 82 Сообщения: 948 Участник с: 14 мая 2009	Была тут уже тема, где все решилось банальной опечаткой, у меня же опечаток нет, а проблема аналогична - демоны стартуют до сети. У меня парк машин, подключенных к домену, соответственно необходимо в первую очередь поднять сеть, потом nslcd демон, который разрезолвит все с домена, а потом уже можно общей кучей стартовать все остальное. Бьюсь над nslcd, прописал и After, и Requires строчки, писал в них уже и network.service, и net-auto-wired.service, и [email protected] e, пробовал даже без netcfg, с помощью сервиса [email protected] e сделать (ибо сетевая всегда одна, всегда по проводам - следовательно eth0 и всегда по DHCP получает IPшник). Все равно все 3 демона, зависящие от сети (nslcd, avahi-daemon и openntpd) не загружаются, показывают статус failed. Что вообще можно придумать, как понять логику systemd в вопросе с сетью?

# 9 лет, 10 месяцев назад

Сообщения: 948

Участник с: 14 мая 2009

Была тут уже тема, где все решилось банальной опечаткой, у меня же опечаток нет, а проблема аналогична - демоны стартуют до сети. У меня парк машин, подключенных к домену, соответственно необходимо в первую очередь поднять сеть, потом nslcd демон, который разрезолвит все с домена, а потом уже можно общей кучей стартовать все остальное. Бьюсь над nslcd, прописал и After, и Requires строчки, писал в них уже и network.service, и net-auto-wired.service, и [email protected] e, пробовал даже без netcfg, с помощью сервиса [email protected] e сделать (ибо сетевая всегда одна, всегда по проводам - следовательно eth0 и всегда по DHCP получает IPшник). Все равно все 3 демона, зависящие от сети (nslcd, avahi-daemon и openntpd) не загружаются, показывают статус failed. Что вообще можно придумать, как понять логику systemd в вопросе с сетью?

sleepycat	# 9 лет, 10 месяцев назад
Темы: 98 Сообщения: 3291 Участник с: 19 июля 2011	network.target ? там не очепятка? Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

sleepycat

# 9 лет, 10 месяцев назад

Темы: 98

Сообщения: 3291

Участник с: 19 июля 2011

network.target ? там не очепятка?

Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

lampslave	# 9 лет, 10 месяцев назад
Темы: 32 Сообщения: 4801 Участник с: 05 июля 2011	А в systemctl status демон никакой наводящей информации нет? И сами юниты покажите на всякий случай. Мало ли что.

ProFfeSsoRr	# 9 лет, 10 месяцев назад
Темы: 82 Сообщения: 948 Участник с: 14 мая 2009	network.target ? там не очепятка? ну да, конечно же network.target, он был в юнитах по умолчанию вписан, а все остальные мною перечисленные варианты я уже сам пробовал вписывать. И сами юниты покажите на всякий случай. Ну openntpd и avahi-daemon - стандартные юниты из их пакетов, мною никак, кроме строк After и Requires не измененные. На nslcd пришлось писать юнит самому, точнее - скопировать его с Fedora :) [Unit] Description=Naming services LDAP client daemon. After=syslog.target network.target Requires=network.target [Service] Type=forking PIDFile=/var/run/nslcd/nslcd.pid ExecStart=/usr/sbin/nslcd [Install] WantedBy=multi-user.target Я пробовал убирать syslog.target (для чистоты эксперимента) - тоже не помогло. А в systemctl status демон никакой наводящей информации нет? все трое по таймауту отваливаются. avahi-daemon пишет, что resolv.conf нет (а откуда ж ему взяться-то, когда сети еще нет), остальные ничего не пишут кроме того, что по таймауту были убиты. Когда сеть поднята - все трое запускаются по systemctl start без проблем, так что ни на что кроме того, что сеть не успевает подняться к тому моменту, как systemd пытается запустить этих демонов, я не грешу. UPD Хаха, с nslcd все еще веселее, systemctl status nslcd показывает, что nslcd сообщает, что запущен и готов работать, а следующая строчка - Failed to start. Ну и статус юнита - failed (Result:timeout). Это вообще что за ерунда - systemd самовольно прибивает нормально работающего демона? оО

ProFfeSsoRr

# 9 лет, 10 месяцев назад

Темы: 82

Сообщения: 948

Участник с: 14 мая 2009

network.target ? там не очепятка?

ну да, конечно же network.target, он был в юнитах по умолчанию вписан, а все остальные мною перечисленные варианты я уже сам пробовал вписывать.

И сами юниты покажите на всякий случай.

Ну openntpd и avahi-daemon - стандартные юниты из их пакетов, мною никак, кроме строк After и Requires не измененные. На nslcd пришлось писать юнит самому, точнее - скопировать его с Fedora :)

[Unit]
Description=Naming services LDAP client daemon.
After=syslog.target network.target
Requires=network.target
[Service]
Type=forking
PIDFile=/var/run/nslcd/nslcd.pid
ExecStart=/usr/sbin/nslcd
[Install]
WantedBy=multi-user.target

Я пробовал убирать syslog.target (для чистоты эксперимента) - тоже не помогло.

А в systemctl status демон никакой наводящей информации нет?

все трое по таймауту отваливаются. avahi-daemon пишет, что resolv.conf нет (а откуда ж ему взяться-то, когда сети еще нет), остальные ничего не пишут кроме того, что по таймауту были убиты. Когда сеть поднята - все трое запускаются по systemctl start без проблем, так что ни на что кроме того, что сеть не успевает подняться к тому моменту, как systemd пытается запустить этих демонов, я не грешу.

UPD Хаха, с nslcd все еще веселее, systemctl status nslcd показывает, что nslcd сообщает, что запущен и готов работать, а следующая строчка - Failed to start. Ну и статус юнита - failed (Result:timeout). Это вообще что за ерунда - systemd самовольно прибивает нормально работающего демона? оО

ProFfeSsoRr	# 9 лет, 10 месяцев назад
Темы: 82 Сообщения: 948 Участник с: 14 мая 2009	Итак, текущий результат такой. Установлены пакеты netcfg и ifplugd, в /etc/network.d лежит файл eth0, который суть есть копия ethernet-dhcp из примеров, в systemd включен юнит net-auto-wired. Сеть поднимается нереально долго, несколько минут (около 3-4), как поднялась - стартует и nslcd и все остальное, и дальше можно работать. nslcd не запускался потому, что нельзя просто тупо копировать чужие файлы - надо было путь до pid файла поправить, сейчас файл выглядит вот так: [Unit] Description=Naming services LDAP client daemon. After=syslog.target network.target Requires=network.target [Service] Type=forking PIDFile=/run/nslcd.pid ExecStart=/usr/sbin/nslcd [Install] WantedBy=multi-user.target Остается понять, почему сеть с systemd поднимается несколько минут вместо нескольких секунд. Я догадываюсь вообще почему - потому что системе нужен доступ до LDAP сервера, которого нет, т.к. нет сети, а нужен потому, что куча всяких gdm и прочего уже запустилась и ждет списка пользователей, и в итоге все это висит-висит, отваливается по таймауту и снова начинает… Один фиг непонятно, как же заставить сеть правильно и гарантировано подниматься (подняли модуль - получили интерфейс - подняли dhcp - отрапортовали, что все прошло успешно и можно идти дальше).

ProFfeSsoRr

# 9 лет, 10 месяцев назад

Темы: 82

Сообщения: 948

Участник с: 14 мая 2009

Итак, текущий результат такой. Установлены пакеты netcfg и ifplugd, в /etc/network.d лежит файл eth0, который суть есть копия ethernet-dhcp из примеров, в systemd включен юнит net-auto-wired. Сеть поднимается нереально долго, несколько минут (около 3-4), как поднялась - стартует и nslcd и все остальное, и дальше можно работать. nslcd не запускался потому, что нельзя просто тупо копировать чужие файлы - надо было путь до pid файла поправить, сейчас файл выглядит вот так:

[Unit]
Description=Naming services LDAP client daemon.
After=syslog.target network.target
Requires=network.target
[Service]
Type=forking
PIDFile=/run/nslcd.pid
ExecStart=/usr/sbin/nslcd
[Install]
WantedBy=multi-user.target

Остается понять, почему сеть с systemd поднимается несколько минут вместо нескольких секунд. Я догадываюсь вообще почему - потому что системе нужен доступ до LDAP сервера, которого нет, т.к. нет сети, а нужен потому, что куча всяких gdm и прочего уже запустилась и ждет списка пользователей, и в итоге все это висит-висит, отваливается по таймауту и снова начинает… Один фиг непонятно, как же заставить сеть правильно и гарантировано подниматься (подняли модуль - получили интерфейс - подняли dhcp - отрапортовали, что все прошло успешно и можно идти дальше).

kurych	# 9 лет, 10 месяцев назад
Темы: 0 Сообщения: 1394 Участник с: 06 ноября 2011	ProFfeSsoRr Остается понять, почему сеть с systemd поднимается несколько минут вместо нескольких секунд. В качестве предположения: у Вас подключение хостов, случайно, не через коммутатор Cisco какой-нибудь происходит?

nafanja	# 9 лет, 10 месяцев назад
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	Могу предположить что сеть пытается настроится перед загрузкой сетевых устройств. Я когда то вышел из этого положения вот так /etc/systemd/system/netcfg.service .include /usr/lib/systemd/system/netcfg.service [Unit] Requires=systemd-udev-settle.service After=systemd-udev-settle.service [Service] Restart=on-failure RestartSec=60 Соответственно нужно подкорректировать нужные сервисы настраивающие подключение к сети тут насильно запускается сервис systemd-udev-settle.service (этот сервис отрабатывает после того как udev закончит работу), и текущий сервис должен отработать после systemd-udev-settle.service, если текущий сервис отработал с ошибкой, то подождать 60сек и повторить попытку. соответственно остальные сервисы зависящие от network.target должны будут ждать пока правильно не отработает текущий сервис. Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

nafanja

# 9 лет, 10 месяцев назад

Темы: 94

Сообщения: 9252

Участник с: 02 июня 2012

заблокирован

Могу предположить что сеть пытается настроится перед загрузкой сетевых устройств.
Я когда то вышел из этого положения вот так
/etc/systemd/system/netcfg.service

.include /usr/lib/systemd/system/netcfg.service
[Unit]
Requires=systemd-udev-settle.service
After=systemd-udev-settle.service
[Service]
Restart=on-failure
RestartSec=60

Соответственно нужно подкорректировать нужные сервисы настраивающие подключение к сети

тут насильно запускается сервис systemd-udev-settle.service (этот сервис отрабатывает после того как udev закончит работу), и текущий сервис должен отработать после systemd-udev-settle.service, если текущий сервис отработал с ошибкой, то подождать 60сек и повторить попытку.
соответственно остальные сервисы зависящие от network.target должны будут ждать пока правильно не отработает текущий сервис.

Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874

ProFfeSsoRr	# 9 лет, 10 месяцев назад
Темы: 82 Сообщения: 948 Участник с: 14 мая 2009	у Вас подключение хостов, случайно, не через коммутатор Cisco какой-нибудь происходит? нет, DHCP сервер - тоже Arch (правда чуть постарее, там еще 3.5.6 ядро), между сервером и клиентами свитч D-Link управляемый, 3052. Могу предположить что сеть пытается настроится перед загрузкой сетевых устройств. я тоже к этому склоняюсь тут насильно запускается сервис systemd-udev-settle.service (этот сервис отрабатывает после того как udev закончит работу), и текущий сервис должен отработать после systemd-udev-settle.service, если текущий сервис отработал с ошибкой, то подождать 60сек и повторить попытку. хм, а вот до этого я не докопался, сейчас буду экспериментировать, спасибо.

ProFfeSsoRr

# 9 лет, 10 месяцев назад

Темы: 82

Сообщения: 948

Участник с: 14 мая 2009

у Вас подключение хостов, случайно, не через коммутатор Cisco какой-нибудь происходит?

нет, DHCP сервер - тоже Arch (правда чуть постарее, там еще 3.5.6 ядро), между сервером и клиентами свитч D-Link управляемый, 3052.

Могу предположить что сеть пытается настроится перед загрузкой сетевых устройств.

я тоже к этому склоняюсь

тут насильно запускается сервис systemd-udev-settle.service (этот сервис отрабатывает после того как udev закончит работу), и текущий сервис должен отработать после systemd-udev-settle.service, если текущий сервис отработал с ошибкой, то подождать 60сек и повторить попытку.

хм, а вот до этого я не докопался, сейчас буду экспериментировать, спасибо.

kurych	# 9 лет, 10 месяцев назад
Темы: 0 Сообщения: 1394 Участник с: 06 ноября 2011	ProFfeSsoRr между сервером и клиентами свитч D-Link управляемый, 3052. С D-Link 3052 лично не сталкивался. Но, т.к. он является управляемым свичем, то, скорее всего, на нем включен протокол STP (spanning tree protokol). По крайней мере, могу судить по коммутаторам Cisco. При включенном STP порт первые 40-50 секунд пытается определить, нет ли в сети петель. И только после этого порт становится доступен для передачи трафика. Глянул мельком на мануал этого 3052 - там еще их собственный протокол какой-то есть (loop detection). Так что рекомендую изучить документацию по настройке коммутатора и отключить на портах, которые идут к серверам и рабочим станциям, stp и другие ненужные в этом случае фичи. В цисковских терминах это: перевести порт в access mode и и включить spanning-tree portfast на интерфейсе.

kurych

# 9 лет, 10 месяцев назад

Темы: 0

Сообщения: 1394

Участник с: 06 ноября 2011

ProFfeSsoRr
между сервером и клиентами свитч D-Link управляемый, 3052.

С D-Link 3052 лично не сталкивался. Но, т.к. он является управляемым свичем, то, скорее всего, на нем включен протокол STP (spanning tree protokol). По крайней мере, могу судить по коммутаторам Cisco. При включенном STP порт первые 40-50 секунд пытается определить, нет ли в сети петель. И только после этого порт становится доступен для передачи трафика. Глянул мельком на мануал этого 3052 - там еще их собственный протокол какой-то есть (loop detection).
Так что рекомендую изучить документацию по настройке коммутатора и отключить на портах, которые идут к серверам и рабочим станциям, stp и другие ненужные в этом случае фичи. В цисковских терминах это: перевести порт в access mode и и включить spanning-tree portfast на интерфейсе.

ProFfeSsoRr	# 9 лет, 10 месяцев назад
Темы: 82 Сообщения: 948 Участник с: 14 мая 2009	При включенном STP порт первые 40-50 секунд пытается определить, нет ли в сети петель. И только после этого порт становится доступен для передачи трафика. про это в курсе, выключено. Да и если перезагружать машину - порт не отцепляется. А я вообще на виртуалке тестирую - физическая машина-то порт держит поднятым постоянно и соответственно даже включенный STP никак бы не помешал ;) Сегодня к сожалению приболел и был дома, завтра продолжу эксперименты и отпишусь.

ProFfeSsoRr

# 9 лет, 10 месяцев назад

Темы: 82

Сообщения: 948

Участник с: 14 мая 2009

При включенном STP порт первые 40-50 секунд пытается определить, нет ли в сети петель. И только после этого порт становится доступен для передачи трафика.

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

Сегодня к сожалению приболел и был дома, завтра продолжу эксперименты и отпишусь.