systemd: гонка и дедлок зависимостей служб?

чтото у тебя дополнительно завязалось…
куча служб с After=network-online.target и все работает…
приведи текст юнита

Именно. В этой системе тоже есть такие службы, но проблема появляется только при добавлении одной описанной зависимости.

Зависимая служба – miniupnpd, если кому интересно. От нее, само-собой, никакие другие службы не зависят уже.

networkmanager всякий не используется в системе? У него свой -wait-online юнит, насколько я помню. И это может сработать как дедлок, да.

Приведи хотя бы примерный код этого ethX.link и юнита падающей сетевой службы

Ситуация оказалась немного иной. Оказывается я правил не тот файл.

Сначала я поставил miniupnpd из дебиановской репы, но там тотально неработоспособная фигня в данный момент лежит, поэтому скачал с сайта авторов и поставил руками более свежую версию. А в ней нет systemd-юнита, только скрипт init.d, из которого systemd-sysv-generator при каждой загрузке генерит юнит и кладет его совсем в другое место, о котором я не знал.

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

В init.d-скрипте такие зависимости:

# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog

Из них генерится юнит с такими

Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=remote-fs.target

Если подправить init.d так:

# Required-Start:    $remote_fs $network $syslog
# Required-Stop:     $remote_fs $network $syslog

то генерится такое:

Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=remote-fs.target
After=network-online.target
Wants=network-online.target

Вроде то что надо, и стартует без затыков, но проблему не решает!

Причем банальный sleep 5 перед start-stop-daemon помогает на ура, но это не комильфо, как по мне.

networkmanager всякий не используется в системе?

Нет.

примерный код этого ethX.link

Прошу прощения, это не в .link (там только привязка имени к MAC), а в .network

[Match]
Name=ethWAN

[Network]
Address=192.168.100.1/24
ConfigureWithoutCarrier=yes

и юнита падающей сетевой службы

# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/miniupnpd
Description=LSB: MiniUPnPd port-forwarding daemon
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=remote-fs.target
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/miniupnpd start
ExecStop=/etc/init.d/miniupnpd stop
ExecReload=/etc/init.d/miniupnpd reload

Вроде то что надо, и стартует без затыков

да, в справке сустемд явно указано

systemd automatically adds dependencies of type Wants= and After= for this target unit to all SysV init script service units with an LSB header referring to the «$network» facility.

проблема в том что этот network-online.target срабатывает при онлайне хотя бы одного любого сетевого подключения. А тебе как я понимаю нужно не любое, а одно конкретное. Тут похоже надо зависеть напрямую от шаблонного варианта wait-online, указав в шаблоне нужное подключение

проблема в том что этот network-online.target срабатывает при онлайне хотя бы одного любого сетевого подключения

Я пробовал с этим бороться принудительным RequiredForOnline=yes, но ни на что не повлияло.

надо зависеть напрямую от шаблонного варианта wait-online, указав в шаблоне нужное подключение

Брагодарю за идею, это вполне себе вариант. Особенно если в продакшене WAN будет по DHCP адрес получать (пока не известно как там на месте все настроено) и задержка готовности интерфейса еще увеличится.

надо зависеть напрямую от шаблонного варианта wait-online, указав в шаблоне нужное подключение

А можно ли как-то прописать systemd-зависимость в init.d-скрипт? Или как-то иначе заставить systemd-sysv-generator добавить ее при генерации юнита?

по мне так проще будет пристрелить init.d скрипт, чтоб не мучался.
написать адекватный юнит в /etc/systemd/system/ и плюс сохранить его в архиве на случай реинкарнации операционки, miniupnpd все равно ставить ручками…

Да, так и сделал. Чего-то зря я залип на init.d

можно попробовать прокинуть патч мейнтейнеру… но придется еще поковыряться.

Патч на создание systemd-юнита? Не думаю, что проканает.

Раз его до сих пор нет в авторской сборке, значит они этого просто не хотят (идейные противники systemd, например).

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

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