systemd: юниты, перезапуск, журнал

Описание сервиса и перечитывание

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

Деталь, на которой теряют часы: systemd читает эти файлы при старте системы и по отдельной команде перечитывания, а не при каждом обращении. Команда перезапуска сервиса берёт то описание, которое уже загружено в память. Поэтому правильный порядок - сначала правка файла, потом перечитывание, потом перезапуск. Само перечитывание безопасно и работающие службы не трогает, а команда состояния честно предупреждает, что файл на диске изменился.

// Второй практический момент - куда писать правки. Если менять файл, пришедший с пакетом, обновление пакета его перезапишет вместе с вашими изменениями. Поэтому правки кладут отдельным маленьким файлом-дополнением: он лежит рядом, применяется поверх и обновление его не трогает.

юнит

текстовое описание службы: что запускать и как себя вести

перечитывание описаний

отдельная команда; без неё перезапуск берёт старое описание из памяти

Политика перезапуска и её ограничитель

Вернусь к настоящим значениям с сервера. Restart=on-failure считает провалом ненулевой код выхода, обрыв сигналом, истёкшее отведённое на запуск время. А вот чистый выход с кодом 0 при такой политике - успех, и перезапуска не будет. Это регулярная ловушка: сервис «сам себя выключил», вернув ноль, и systemd честно оставил его выключенным. Если служба обязана работать всегда, ставят Restart=always - именно так настроен docker на моём сервере.

Но перезапускать бесконечно нельзя: сервис, который падает мгновенно, съел бы машину. Поэтому у политики есть ограничитель из двух чисел - сколько попыток и за какое окно. У docker это 3 попытки за минуту, у cron - 5 за 10 секунд. Исчерпав лимит, systemd перестаёт пытаться и оставляет службу в состоянии отказа, пока человек не разберётся.

// Пауза между попытками задаётся отдельно: у docker 2 секунды, у cron 100 миллисекунд. Сумма настроек и определяет, как быстро сервис сдастся: три попытки по 2 секунды - это меньше десяти секунд до окончательного отказа, и в мониторинге это надо ловить, а не полагаться, что «systemd поднимет».

Restart=on-failure

перезапуск при сбое; выход с кодом 0 сбоем не считается

ограничитель попыток

сколько перезапусков за какое окно; исчерпан - служба остаётся в отказе

Журнал и расписания

Всё, что служба пишет в вывод, попадает в системный журнал: его смотрят по имени службы, следят в реальном времени, фильтруют по важности и по периоду. Но есть настройка, из-за которой логи исчезают. При режиме хранения «автоматически» журнал пишется на диск, только если существует каталог /var/log/journal; иначе он живёт во временной памяти и после перезагрузки пропадает целиком. На моём сервере каталог есть, журнал занимает 38,5 мегабайта и перезагрузку переживает.

Регулярные задачи systemd умеет запускать сам, без cron: расписание задаётся человекочитаемой строкой. Проверил разбор на живой машине: строка «Mon *-*-* 04:00:00» означает ближайший понедельник в 04:00, «*-*-01 00:00:00» - первое число каждого месяца, а короткое слово «daily» разворачивается в «*-*-* 00:00:00». Систему можно спросить, когда сработает в следующий раз, и она ответит точной датой.

// Преимущество перед cron практическое: код возврата и вывод задачи видны обычными командами, повторный запуск не начнётся, пока предыдущий не закончил, а отдельный флаг заставляет догнать запуск, пропущенный из-за того, что машина была выключена. У cron пропущенное просто теряется.

хранение журнала

без каталога /var/log/journal логи живут в памяти и гибнут при перезагрузке

таймер вместо cron

расписание строкой, вывод в общем журнале, догон пропущенного запуска

Как отвечать: «Поправил описание службы, сделал restart - параметры старые. Почему?»

Потому что systemd держит описания служб в памяти и перечитывает их только по отдельной команде или при старте системы. Команда перезапуска берёт то описание, которое уже загружено, и честно перезапускает службу со старыми параметрами. Правильный порядок такой: правка файла, затем перечитывание описаний, затем перезапуск службы. Само перечитывание безопасно, работающие службы оно не трогает. Кстати, команда состояния службы в такой ситуации прямо предупреждает, что файл на диске изменился, - это первое, на что стоит посмотреть. И отдельно про то, куда писать правки: если менять файл, пришедший с пакетом, следующее обновление пакета его перезапишет вместе с изменениями. Поэтому я всегда кладу правки отдельным файлом-дополнением, который применяется поверх пакетного и обновление его не трогает.

Ответ даёт точный порядок команд, объясняет причину и добавляет практику с отдельным файлом правок, которой нет в учебниках.

На чём валятся

• −Забывают перечитать описания и долго ищут, почему правка не применилась.
• −Ждут перезапуска при политике «только при сбое» после выхода с кодом 0 - это успех.
• −Полагаются на автоперезапуск, не глядя на ограничитель: 3 попытки за минуту, и служба остаётся в отказе.
• −Не создают каталог для журнала и теряют все логи при перезагрузке.