RuntimeMaxSec: как systemd убивает сервис, который работает слишком долгоИногда сервис не падает и не зависает в классическом смысле - он просто продолжает работать часами, хотя по логике приложения должен завершиться.
В systemd для этого есть
RuntimeMaxSec=.▪️Ограничиваем время жизни сервиса
В unit-файле:
[Service]
ExecStart=/usr/local/bin/job.sh
RuntimeMaxSec=30min
После 30 минут с момента запуска systemd остановит сервис.
Для более точного ограничения:
RuntimeMaxSec=1h 30min
▪️Что происходит после истечения времени
Это не просто
kill -9.По умолчанию systemd инициирует обычную остановку сервиса. Если процесс не завершится в течение
TimeoutStopSec=, systemd применит настроенное принудительное завершение.Например:
[Service]
RuntimeMaxSec=30min
TimeoutStopSec=20s
Получается цепочка:
30 мин → остановка
↓
20 сек на graceful shutdown
↓
принудительное завершение
▪️Проверить фактические параметры
После запуска:
systemctl show myjob.service \
-p RuntimeMaxUSec \
-p TimeoutStopUSec
А текущий статус:
systemctl status myjob.service
▪️Что будет при следующем запуске
RuntimeMaxSec не запрещает сервису запускаться снова.Если unit настроен так:
[Service]
Restart=on-failure
RuntimeMaxSec=30min
важен результат завершения и дополнительные параметры restart policy.
Сервис может быть запущен systemd снова после остановки.
Поэтому
RuntimeMaxSec стоит рассматривать вместе с Restart=, а не как самостоятельный механизм watchdog.▪️Практический сценарий
Допустим, есть batch-задача:
[Service]
Type=oneshot
ExecStart=/opt/scripts/import.sh
RuntimeMaxSec=2h
Если импорт по какой-то причине зависнет на бесконечной операции, systemd не оставит процесс работать сутки.
▪️Важный нюанс
RuntimeMaxSec - это лимит общего времени работы, а не проверка того, отвечает ли приложение.Если сервис должен завершаться за 5 минут, но иногда работает 10 минут по штатной причине, такой лимит будет ошибкой конфигурации.
Для контроля «жив ли сервис и отвечает ли он» нужны другие механизмы.
BashTex 📱 #bash #linux