systemd умеет не только запускать и перезапускать сервисы, но и разговаривать с ними. Механизм notify — это способ для демона сказать: «я реально готов», «я перезагружаю конфиг», «я живой, не убивай меня».
Зачем вообще нужен notify
Классический юнит Type=simple врёт сам себе: как только процесс стартанул — считаем сервис запущенным. А в реальности БД ещё поднимает файлы, веб‑сервер открывает сокеты, а ваш сервис в этот момент не готов обслуживать запросы.
Type=notify + systemd-notify решают эту проблему: systemd ждёт явного сигнала READY=1, и только после этого считает сервис активным и запускает зависящие юниты.
Как это устроено под капотом
• При старте юнита с Type=notify systemd прокидывает в окружение переменную NOTIFY_SOCKET — путь до UNIX‑сокета, куда сервис должен отправлять уведомления.
• Сам сервис либо вызывает
sd_notify() из libsystemd, либо запускает утилиту systemd-notify, чтобы отправить строки вида READY=1, STATUS=…, RELOADING=1, STOPPING=1, WATCHDOG=1.systemd-notify — это просто тонкая обёртка над
sd_notify(), которая делает этот протокол доступным из shell‑скриптов и простых сервисов без прямой линковки с libsystemd. Она умеет:• отправлять
--ready, --reloading, --stopping, --status="...", --pid=...• работать в режиме
--exec: сначала отправить уведомление, потом exec процесса; или --fork: подождать READY=1 от дочернего процесса и вернуть его PID.Watchdog и «я живой»
Через этот же канал работает и watchdog. Если в юните настроен
WatchdogSec=…, systemd ждёт периодических сообщений WATCHDOG=1. Пока они приходят — сервис считается здоровым, как только нет — менеджер перезапускает его. Это даёт очень дешёвый health‑check без дополнительных скриптов и cron’ов: сервис сам регулярно подтверждает, что цикл событий жив и не завис.
🐸 Библиотека devops'a
#арсенал_инженера