Наш вартовий перезапустив служби, які ми зупинили навмисно

Операції2026-10-31

Один із наших вартових запускає будь-яку з наших служб, яка увімкнена, але не працює. Двічі в жовтні він запускав служби, які ми зупинили навмисно. Другого разу відвідувачі одного з наших сайтів отримували помилки приблизно 45 хвилин.

Чому цей вартовий існує

Служба, яка коректно завершується при отриманні SIGTERM, наприклад, тому що її вбили за іменем, для systemd не вважається «непрацюючою». Restart=on-failure не повертає її до життя, а systemctl --failed не показує її в списку. Вона залишається зупиненою, поки хтось випадково не помітить. Тому вартовий шукає служби, які увімкнені, але не працюють, і запускає їх.

Проблема в тому, що служба, яку ви зупинили вручну, виглядає точно так само.

Перший випадок

7 жовтня ми зупинили відеопроцесор командою systemctl stop о 12:47, щоб відредагувати його чергу завдань. О 12:55 він знову працював: вартовий його запустив.

Другий випадок

21 жовтня нам потрібна була пам’ять машини, яка також обслуговує два наші сайти, для тестування моделі. Скрипт зупинив веб-застосунки сайтів, задачу синхронізації та контейнер бази даних, знову ж таки за допомогою systemctl stop. Приблизно через п’ять хвилин таймер, який стежить за сайтами, а о 19:14 вартовий, повернули тунель і веб-застосунки.

Тунель знову почав приймати трафік, але веб-застосунки не могли відповісти: модель, що тестувалася, займала 114 ГіБ пам’яті машини. З приблизно 19:14 до 20:00 деякі відвідувачі отримували помилки 502. О 20:00 ми вимкнули тунель, веб-застосунки та задачу синхронізації, а також зупинили таймер спостереження.

Правило, яке ми використовуємо зараз

Призупиняйте службу, вимикаючи її: sudo systemctl disable --now <unit>. Повертайте її командою sudo systemctl enable --now <unit>. Наш вартовий дивиться лише на увімкнені служби, тому вимкнену він не чіпає.
Призупиняйте все, що може її повернути: тунель перед нею та будь-який таймер, який за нею стежить.
Короткочасна зупинка — це перегони. Якщо ви використовуєте лише stop, завершіть роботу до наступної перевірки, яка на наших машинах відбувається протягом кількох хвилин.

Ще дві пастки systemd за тих самих місяців

systemctl mask --runtime нічого не робить для файлу юніта в /etc/systemd/system. Юніти в /etc мають пріоритет над маскою в /run, тому команда виконується успішно, але сервіс все одно запускається. Щоб утримати сервіс, ми використовуємо drop-in з ConditionPathExists=!/etc/<name>.hold: поки цей файл існує, сервіс не запускається, ні під час завантаження, ні вручну.
systemctl is-active називає запущений сервіс типу oneshot неактивним. Поки сервіс Type=oneshot працює, його стан — «activating», тому is-active виводить це значення та повертає 3. Цикл на кшталт while systemctl is-active --quiet job.service; do sleep 60; done, призначений для очікування нічного завдання, завершується одразу. Замість цього перевіряйте стан: active, activating, reloading або deactivating означають, що він ще працює.

Factory Floor стежить за увімкненими сервісами, які не працюють. За замовчуванням він лише повідомляє про них і запускає їх, лише якщо ви увімкнете цю опцію. Починаючи з версії 1.0.3, його сповіщення також містить інструкцію, як навмисно поставити сервіс на паузу, а в runbook зазначено те саме.