Почему systemd не перезапускает этот сервис с Restart = всегда?

Question

У меня на сервере работает демон резервного копирования, который выходит из строя каждые несколько дней. Я не уверен почему. В долгосрочной перспективе я хотел бы выяснить, почему и исправить это, но в то же время я бы хотел, чтобы systemd перезапустил его, когда он выйдет из строя.

Он имеет скрипт инициализации SysV в старом стиле, который выбирается systemd-sysv-generator. Очевидно, что когда происходит сбой, это происходит с нулевым ("успешным") кодом завершения. Чтобы попытаться перезапустить его после этих сбоев, я добавил override.conf:

~$ cat /etc/systemd/system/crashplan.service.d/override.conf
[Service]
Restart=always

systemd, похоже, подхватывает это:

roberts:~$ sudo systemctl show crashplan.service | grep Restart
Restart=always
RestartUSec=100ms

Тем не менее, когда я проверил это через несколько дней, я обнаружил:

roberts:~$ sudo systemctl status crashplan.service
● crashplan.service - LSB: CrashPlan Engine
   Loaded: loaded (/etc/init.d/crashplan; bad; vendor preset: enabled)
  Drop-In: /etc/systemd/system/crashplan.service.d
           └─override.conf
   Active: active (exited) since Thu 2017-01-05 00:33:50 PST; 5 days ago
     Docs: man:systemd-sysv-generator(8)

Jan 05 00:33:50 roberts systemd[1]: Stopped LSB: CrashPlan Engine.
Jan 05 00:33:50 roberts systemd[1]: Starting LSB: CrashPlan Engine...
Jan 05 00:33:50 roberts crashplan[25491]: Starting CrashPlan Engine ... Using standard startup
Jan 05 00:33:50 roberts crashplan[25491]: OK
Jan 05 00:33:50 roberts systemd[1]: Started LSB: CrashPlan Engine.

Итак ... systemd, кажется, думает, что он не работает и это круто? Там нет журналов, предполагающих, что он даже пытался перезапустить его? Я даже не могу понять, как сказать, когда он разбился. Что тут происходит?

Answer 1

Когда скрипт init.d не указывает файл PID, его автоматически сгенерированный модуль имеет RemainAfterExit=yes. В большинстве случаев такие сценарии представляют собой задачи с одним выстрелом, которые не имеют длительного процесса, поэтому этот параметр делает такие модули активными даже после завершения процесса.

Это позволяет администратору "останавливать" такой модуль вручную (например, "запуск" /etc/init.d/iptables загружает правила брандмауэра и "остановка" приводит к их сбросу). Однако, поскольку устройство всегда "активно", это означает, что логика перезапуска никогда не сработает. ( В конце концов, нет ничего , чтобы перезагрузить.)

Решением здесь было бы написать собственный файл systemd .service для CrashPlan - или, по крайней мере, заставить демона создать pidfile и добавить # pidfile: /run/... в начальный скрипт соответственно.

...В качестве альтернативы сначала запустите systemctl cat crashplan.service чтобы просмотреть полное содержимое модуля, затем вручную отмените все неправильные параметры: RemainAfterExit, GuessMainPID и т.д.

См. Также commit f87883039 и файл sysv-generator.c line 197.