LINUX.ORG.RU
ФорумAdmin

systemd: запустить после того, как поднялась сеть

 ,


1

1

Есть юнит для демона автоматического обновления динамического DNS. Написал в нём: After=network-online.target, однако, сразу при старте системы он не может подключиться к серверам провайдера динамического DNS, хотя при следующей попытке всё получается. Что я сделал не так?

★★

ЕМНИП

### BEGIN INIT INFO
# Required-Start: $network
### END INIT INFO

bvn13 ★★★★★
()

Requires=network-online.target можно еще дописать и NetworkManager-wait-online.service enable сделать, если у тебя NM. Системде ж не знает, как определить, онлайн ты или нет.

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

Системде ж не знает, как определить, онлайн ты или нет.

И это они считают системой инициализации?

devl547 ★★★★★
()
Ответ на: комментарий от devl547

А как это вообще связано? Напомню, что тут разделяются понятия «онлайн» и «поднятие сети» (инициализация сетевого интерфейса).

unikum ★★★★★
()
Ответ на: комментарий от unikum

Вот так и связано, что делать если сервис зависит не просто от поднятого коннекта, а ещё и от доступа в сеть?

Как же так Лёня не подумал.

devl547 ★★★★★
()
Ответ на: комментарий от devl547

network-online.target is a target that actively waits until the nework is «up», where the definition of «up» is defined by the network management software. Usually it indicates a configured, routable IP address of some kind. It's primary purpose is to actively delay activation of services until the network is set up. It is an active target, meaning that is may be pulled in by the services requiring the network to be up, but is not pulled in by the network management service itself. By default all remote mounts defined in /etc/fstab pull this service in, in order to make sure the network is up before it is attempted to connect to a network share. Note that normally, if no service requires it, and if not remote mount point is configured this target is not pulled into the boot, thus avoiding any delays during boot should the network not be available. It is strongly recommended not to pull in this target too liberally: for example network server software should generally not pull this in (since server software generally is happy to accept local connections even before any routable network interface is up), it's primary purpose is network client software that cannot operate without network.

yumko ★★
()
Ответ на: комментарий от devl547

«Доступ в сеть» весьма абстрактное понятие. К примеру, у провайдера отвалился сегмент интернетов. Есть у тебя «доступ в сеть» или нет?

Или допустим у тебя два сетевых интерфейса. К одному подключен телевизор, другой к роутеру. С телеком поднялся, с роутером нет. Как определить, есть ли у тебя «доступ в сеть»?

Так что ты волен сам набыдлить юнит с критерием, который тебе по душе. Я например писал юнит который не завершается пока не попингует 8.8.8.8 :)

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

Я сделал так: добавил NetworkManager-wait-online в network-online.target и проставил юниту After=network-online.target. Вроде, всё в порядке и работает, как надо, но вот какой вопрос: можно ли сделать так, чтобы если вдруг сеть не поднимается, загрузка не задерживалась?

Norong ★★
() автор топика
Ответ на: комментарий от Norong

cast intelfx

И ещё - правильно ли я поступил, что установил Requires? Прочитав ман, я понял: если указан Requires, то если зависимости не запускаются, то основной юнит тоже не запускается. В этом случае, кажется, это - именно то, что нужно, ведь служба динамического DNS бесполезна без активного соединения.

Norong ★★
() автор топика
Ответ на: комментарий от Norong

можно ли сделать так, чтобы если вдруг сеть не поднимается, загрузка не задерживалась?

Загрузка не будет задерживаться. systemd на то и systemd, чтобы все юниты в отсутствие зависимостей запускались параллельно.

Если от твоего dyndns.service ничего не зависит (т. е. если ни в одном юните нет After=dyndns.service), то загрузка продолжится и завершится, невзирая на то, что этот твой юнит застопорился.

И ещё - правильно ли я поступил, что установил Requires? Прочитав ман, я понял: если указан Requires, то если зависимости не запускаются, то основной юнит тоже не запускается.

В принципе, да, это то, что нужно. Другой вопрос, что systemd — это зависимостная модель, а не событийная, т. е. когда сеть всё-таки соизволит подняться (скажем, через час) — dyndns.service автоматически не запустится.

P. S.: так ты сделал

Requires=network-online.target
After=network-online.target
или просто
After=network-online.target
?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Понял, спасибо. Правильно ли я понимаю, что если я проставлю Wants, то даже если network-online не взлетит (т.е. не взлетит NetworkManager-wait-online), то dyndns всё равно взлетит?

И ещё. Я тут посмотрел на systemctl list-dependencies: http://pastebin.com/EkdYjp7X

Мне не совсем ясны первые строки - сказано, что default.target втягивает следующие юниты. Они же упомянуты как втягиваемые multi-user.target чуть ниже. Однако, вроде, default.target - суть симлинк на multi-user.target. Откуда тогда такое выделение этих нескольких юнитов среди всех остальных, которые требуются multi-user.target'ом?

Norong ★★
() автор топика
Ответ на: комментарий от intelfx

Я сделал Requires и After. Сначала был только After, потом дописал и Requires.

Norong ★★
() автор топика
Ответ на: комментарий от intelfx

А если сеть поднимется не через час а через 5 минут, dyndns.service запустится или нет? Т.е получается у сервиса есть какой-то таймаут ожидания другого сервиса?

anonymous
()
Ответ на: комментарий от Norong

Правильно ли я понимаю, что если я проставлю Wants, то даже если network-online не взлетит (т.е. не взлетит NetworkManager-wait-online), то dyndns всё равно взлетит?

Да. Причём чтобы достичь обратного эффекта, Wants нужно заменить на Requires в обоих местах:

  1. сделать так, чтобы network-online.target требовала NetworkManager-wait-online.service,
  2. сделать так, чтобы dyndns.service требовал network-online.target.
intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от anonymous

Почти. Существует таймаут запуска сервиса (TimeoutStartSec=, 90 секунд по умолчанию). При его достижении юнит сваливается в failed (если не настроить Restart= етц.) и дальше по цепочке.

Ещё есть таймаут задачи (JobTimeoutSec=, по умолчанию отключен) — это время, по достижении которого systemd фейлит цепочку зависимостей (но не трогает сам тот юнит, в котором директива).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 6)
Ответ на: комментарий от intelfx

Тогда, наверное, более просто будет проставить у dyndns.service прямую зависимость Requires от NetworkManager-wait-online.service, а из network-online.target NetworkManager-wait-online можно выкинуть, чтобы не менять системные юниты, но при этом добиться нужного функционала?

Недавно патчем в эту прогу (она inadyn зовётся, кстати) добавили поддержку systemd с таким юнитом:

[Unit]
Description=DDNS client
After=syslog.target network.target

[Service]
ExecStart=/usr/bin/inadyn
Restart=always

[Install]
WantedBy=multi-user.target

Поскольку в стандартной конфигурации Debian эта прога не требует syslog, а пишет логи самостоятельно, то я убрал зависимость от syslog. Мой текущий юнит так выглядит:

[Unit]
Description=DDNS client
After=network-online.target
Requires=network-online.target

[Service]
ExecStart=/usr/bin/inadyn
Restart=always

[Install]
WantedBy=multi-user.target
Правильно ли я поступил, что убрал network.target в пользу network-online.target?

С учётом последних сведений, поступивших от тебя, кажется, что он должен выглядеть так:

[Unit]
Description=DDNS client
After=network.target NetworkManager-wait-online.service
After=network.target NetworkManager-wait-online.service

[Service]
ExecStart=/usr/bin/inadyn
Restart=always

[Install]
WantedBy=multi-user.target

Или можно сделать как-то лучше?

Norong ★★
() автор топика
Ответ на: комментарий от intelfx

Я солгал, видимо:

/lib/systemd/system/default.target -> graphical.target
Тогда опять-таки не совсем ясно присутствие таких вещей, как
● ├─exim4.service
● ├─fail2ban.service
● ├─gpm.service
● ├─systemd-readahead-collect.service
● ├─systemd-readahead-replay.service
● ├─systemd-update-utmp-runlevel.service
● ├─tor.service
в этом таргете.

Norong ★★
() автор топика
Ответ на: комментарий от Norong

After=network.target NetworkManager-wait-online.service
After=network.target NetworkManager-wait-online.service

Requires=NetworkManager-wait-online.service
After=network.target NetworkManager-wait-online.service

Wants=network.target (или Requires=) не пишут.

Вот ещё: network.target, network-pre.target, network-online.target.

Note the distinction between this unit and network.target. This unit is an active unit (i.e. pulled in by the consumer rather than the provider of this functionality) and pulls in a service which possibly adds substantial delays to further execution. In contrast, network.target is a passive unit (i.e. pulled in by the provider of the functionality, rather than the consumer) that usually does not delay execution much.

И ещё: Running Services After the Network is up. Там ближе к концу статьи очень хорошо изложено, чем отличаются эти три таргета.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 4)
Ответ на: комментарий от Norong

Это уже у твоего дистрибутива нужно спрашивать, откуда в graphical.target эти юниты.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Спасибо. Кстати, наверное, я всё-таки сделаю

After=network-online.target
Requires=network-online.target
Ведь, если я правильно понимаю, то такое поведение обеспечит следующее: если в течение полутора минут сеть поднимется, то сервис запустится сразу после поднятия сети. Если же сеть не поднимается, то он запускается через полторы минуты (когда оказывается, что сеть не взлетела) и висит. При этом, поскольку он сам связывается с интернетом по таймауту, как только сеть поднимется, он начнёт нормально работать. Кажется, никак иначе без изменений NetworkManager-wait-online такое поведение не огранизовать. Я же правильно понимаю, что вариант с
Requires=NetworkManager-wait-online.service
After=network.target NetworkManager-wait-online.service
Просто пометит сервис, как failed, если сеть не поднимется за полторы минуты?

Norong ★★
() автор топика
Ответ на: комментарий от intelfx

Кстати, я прочитал про Restart=always, но так и не понял, что под этим подразумевается. Автоматический перезапуск сервиса, если процесс завершился любым путём?

Norong ★★
() автор топика
Ответ на: комментарий от Norong

Я же правильно понимаю, что вариант с

Requires=NetworkManager-wait-online.service
After=network.target NetworkManager-wait-online.service

Просто пометит сервис, как failed, если сеть не поднимется за полторы минуты?

Именно так. В общем, дальше решай. Я ж не знаю, что тебе нужно конкретно :)

intelfx ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.