[alibek]

P.S. Судя по результатам strace, systemd пытается искать стартер /etc/init.d/firewall.

Файла там нет, поэтому и выходит такая ошибка.

Но не могу понять, зачем он туда лезет. На старом сервере все прекрасно работает без init.d.

 

P.P.S. На старом сервере еще был симлинк /etc/systemd/system/multi-user.target.wants (указывал на /etc/systemd/system/firewall.service).

По идее этот симлинк создается автоматически (из файла-описания), на старом сервере я его не создавал.

Но на новом сервере он почему-то не создался.

Когда создал вручную - все заработало.

 

Вроде бы смутно вспоминается какой-то баг на systemd, связанный с тем, что он не может делать симлинк на симлинк (то есть в /etc/systemd/system/ нужно копировать сами файлы, а не делать симлинки).

[pppoetest]

P.S. Судя по результатам strace, systemd ...

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

[alibek]

Ну это конечно же малость напрягает. Даже не малость.

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

Система запускается гораздо быстрее (наверное раз в 5), чем SysV.

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

Я на SysV жуткие костыли делал (в rc.local), чтобы это обеспечить.

[snvoronkov]

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

ЧЕГО???

 

Заголовок init скриптов почитать - никак?

 

root@stream:/etc/init.d# head -15 checkroot.sh 
#! /bin/sh
### BEGIN INIT INFO
# Provides:          checkroot mtab
# Required-Start:    mountdevsubfs hostname
# Required-Stop:     
# Should-Start:      keymap hwclockfirst hdparm bootlogd
# Should-stop:
# Default-Start:     S
# Default-Stop:
# X-Interactive:     true
# Short-Description: Check to root file system.
### END INIT INFO

# Include /usr/bin in path to find on_ac_power if /usr/ is on the root
# partition.

[alibek]

Заголовок init скриптов почитать - никак?

Ну во-первых, эти зависимости не генерируются автоматически, нужно запускать update-rc.

А во-вторых, я уже не помню, чем это мне не подошло. Мне нужно было запускать контроллер UniFi (java-приложение) с задержкой, через стартеры в init.d не получилось.

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

 

P.S. И на мой взгляд, заморочки с LSB немногим уступают заморочкам с systemd.

Чтобы написать правильный стартер, времени уходит не меньше, чем на юнит в systemd.

А при этом отследить падение процесса сложнее.

 

У UniFi такие вводные данные:

1. Это java-приложение, запускается через JVM. start-stop-daemon нормально не работает (по крайней мере у меня не получилось его правильно использовать). Вдобавок у меня не получилось передать дополнительные параметры командной строки именно в java-приложение (а не в JVM).

2. Чтобы отследить запуск/остановку/падение, пришлось писать целое сочинение на grep/awk, чтобы найти именно нужный процесс. Ковровая бомбардировка по имени процесса (killall) не подходила, т.к. на этом сервере были еще java-приложения (второй инстанс UniFi для закрытого применения).

3. UniFi при запуске стартовал отдельный инстанс mongo. При закрытии java-приложения через kill этот инстанс mongo оставался активным и перезапуск UniFi не производился (поскольку слушающий порт был уже занят и второй инстанс mongo не мог запуститься). Закрыть именно нужный инстанс mongo было еще сложнее, чем закрыть нужное java-приложение.

Вообщем на LSB я не смог сделать нормальный стартер приложения в init.d, вместо этого у меня был специальный скрипт для старта/рестарта/остановки, который использовал killall, паузу и вычищение следов в виде pid и lock файлов. А на systemd все получилось сделать очень симпатично.

[snvoronkov]

А... Два экземпляра UniFI на одной тачке. Представляю себе сэкас. :-)

[alibek]

В SysV это уже кунг-фу, которое я не умею.

В systemd несколько инстансов одного сервиса реализовать проще, там это как-бы из коробки предусмотрено.

Ну и то, что systemd сам отслеживает падение процессов (вместо шаманства с pid-файлами и monit) — тоже многое упрощает, особенно в случае java-приложений.