Процессы, сигналы и systemd

SIGTERM — это просьба завершиться. Процесс может перехватить его и корректно остановиться: перестать принимать новую работу, завершить текущие запросы, сбросить буферы, закрыть соединения с БД и выйти. Это сигнал kill по умолчанию, и именно его первым отправляют systemd, Docker и Kubernetes. SIGKILL нельзя перехватить, заблокировать или проигнорировать; ядро завершает процесс немедленно, поэтому никакой очистки не происходит, и можно получить повреждённые файлы, зависшие блокировки или потерянные задачи. Правильная процедура: TERM, подождать разумный таймаут, и только если процесс всё ещё жив — KILL. Именно так поступает systemd с TimeoutStopSec.

Я бы не запускал его вручную по SSH. Самый простой надёжный вариант — юнит systemd: запуск под отдельным пользователем, WorkingDirectory и EnvironmentFile для секретов, ExecStart с бинарником node, Restart=on-failure и enable, чтобы приложение стартовало при загрузке. Логи идут в журнал. Альтернативы — pm2, который добавляет кластеризацию и собственную работу с логами и стартует при загрузке через юнит systemd, сгенерированный pm2 startup, или запуск в контейнере с политикой перезапуска. В любом случае я привязываю приложение к localhost, ставлю перед ним nginx для TLS и обрабатываю SIGTERM в коде, чтобы перезапуски проходили без сюрпризов.

Начинаю с uptime и сравниваю load average с nproc. Затем top или htop с сортировкой по CPU, а потом по памяти, чтобы найти тяжёлый процесс. free -h показывает, закончилась ли память и используется ли swap, а journalctl -k или dmesg — не убивал ли процессы OOM killer. Если CPU загружен слабо, а нагрузка высокая, процессы, скорее всего, ждут диск, поэтому я смотрю iostat или значение wa в top, а также df -h на предмет заполненного диска. Наконец, смотрю на сторону приложения: медленные запросы, зависший воркер очереди или всплеск трафика, видимый в access-логе nginx.

restart останавливает сервис и запускает его снова, поэтому есть короткий момент без процесса, и существующие соединения обрываются. reload просит работающий процесс перечитать конфигурацию, обычно отправляя SIGHUP или выполняя настроенную команду ExecReload, и продолжает обслуживать запросы. nginx, например, запускает новые воркеры с новым конфигом и даёт старым завершить свои запросы, так что для пользователей reload незаметен. Не каждый сервис поддерживает reload; systemctl reload-or-restart обрабатывает оба случая. Перед reload nginx я всегда запускаю nginx -t, потому что сломанный конфиг провалит reload, и это лучше поймать заранее.

Для небольшой простой задачи cron вполне подходит, и его синтаксис знают все. Для важных задач я предпочитаю таймеры systemd. Задача запускается как обычный сервис, поэтому её вывод попадает в журнал с временными метками, у неё могут быть лимиты ресурсов и отдельный пользователь, она не запустит вторую копию, пока работает первая, а Persistent=true догоняет запуски, пропущенные, пока сервер был выключен. systemctl list-timers также показывает, когда каждая задача запускалась в последний раз и когда запустится следующий, чего cron не умеет. Цена — два маленьких файла вместо одной строки.

systemctl status name показывает состояние, код выхода и последние строки лога, и часто этого достаточно. Для подробностей journalctl -u name -b показывает весь его вывод с момента загрузки, а -p err отфильтровывает ошибки. Частые причины — неверный путь в ExecStart, отсутствующая переменная окружения, уже занятый порт (проверьте через ss -ltnp), права на файлы для сервисного пользователя или синтаксическая ошибка в самом юните, которую может поймать systemd-analyze verify. Если я правил юнит, убеждаюсь, что выполнил daemon-reload. После исправления systemctl reset-failed сбрасывает состояние ошибки.

У PID 1 особые обязанности. Ядро не применяет к нему обработчики сигналов по умолчанию, поэтому SIGTERM, который приложение явно не обрабатывает, просто игнорируется, и контейнер ждёт таймаута, прежде чем его убьют. PID 1 также должен собирать осиротевших потомков; приложение, запускающее подпроцессы, например shell-обёртку или headless-браузер, накапливает зомби, если никогда не вызывает wait. На хосте PID 1 — это systemd, и он делает и то, и другое. В контейнерах либо используйте крошечный init вроде tini (docker run --init), либо убедитесь, что приложение обрабатывает сигналы и не порождает неуправляемых потомков. Также запускайте приложение в exec-форме в Dockerfile или через exec в entry-скрипте, чтобы сигналы получало оно, а не промежуточный shell.

Все они перезапускают процессы; различия — в охвате и зависимостях. Простой юнит systemd не требует ничего дополнительного, даёт лимиты cgroup, песочницу и логи в журнале и является самым надёжным выбором для одного-двух сервисов на хост. pm2 добавляет удобства для Node, такие как cluster mode по всем ядрам, zero-downtime reload и процесс деплоя, ценой ещё одного демона со своими лог-файлами. supervisor прост и не зависит от языка, популярен для запуска нескольких процессов-воркеров очередей, но собственных лимитов cgroup не имеет. Контейнеры дают воспроизводимые образы и изоляцию, что окупается при большом числе сервисов или команд. Что бы вы ни выбрали, не громоздите менеджеры друг на друга без причины и чётко определите, какой слой отвечает за рестарты, логи и лимиты.

Исходите из того, что что-то обязательно потечёт, и заранее решите, кто должен умереть. Поместите каждый сервис в собственную cgroup с MemoryHigh как мягким лимитом, чтобы ядро сначала отбирало память и замедляло сервис, и MemoryMax как жёстким лимитом, чтобы OOM killer действовал только внутри этой cgroup. Понизьте OOM score критичных сервисов, например базы данных, через OOMScoreAdjust. Позвольте политике рестартов восстанавливать сервис с утечкой и настройте алерты на NRestarts или события OOM, чтобы утечка была видна, а не тихо «лечилась». Оставьте немного swap для поглощения пиков и присмотритесь к systemd-oomd, который может срабатывать раньше при нехватке памяти. Цена в том, что слишком низкие лимиты вызывают рестарты на легитимных пиках, поэтому выставляйте их по наблюдаемому потреблению плюс запас.