Сигналы и grace period: SIGTERM, SIGKILL и PID 1

«Дай процессу сначала закончить» — славная идея, но кто говорит процессу начать заканчивать и сколько у него времени? Ответ — точный контракт между оркестратором и твоим контейнером, и ошибиться в нём — один из самых частых продовых сюрпризов. Команда добавляет чистый SIGTERM-обработчик, который дренирует до 45 секунд, — и обнаруживает, что их запросы всё равно обрываются на полпути на каждом деплое. Обработчик был верен; проблема в том, что сигнал до него не дошёл. Их контейнер стартовал приложение через шелл (sh -c "node server.js"), так что PID 1 был шеллом, шелл не пробросил SIGTERM, и после grace period оркестратор послал единственный сигнал, который никто не может поймать — SIGKILL — прямо сквозь вежливый обработчик, ждавший SIGTERM, которого ему не видать. Shutdown начинается с понимания, какие именно сигналы срабатывают, в каком порядке, какому процессу и против каких часов.

Последовательность завершения

Когда Kubernetes решает остановить под, он запускает фиксированную последовательность — и та же форма держится у большинства планировщиков:

1. Под помечается Terminating и убирается из endpoints сервиса (про эту гонку — в следующем уроке).
2. Запускается preStop hook, если ты его определил. Это команда или HTTP-вызов, выполняемый перед отправкой сигнала, и оркестратор блокируется на нём. Часто используется, чтобы поспать немного, давая маршрутизации стечь, или флипнуть флаг readiness.
3. SIGTERM шлётся в PID 1 контейнера — вежливый сигнал «пожалуйста, остановись». Это момент, когда должен сработать твой обработчик shutdown.
4. Оркестратор ждёт grace period — terminationGracePeriodSeconds, по умолчанию 30 секунд в Kubernetes. Этот таймер покрывает preStop hook и пост-SIGTERM shutdown вместе.
5. Шлётся SIGKILL, если процесс ещё жив, когда таймер истёк. SIGKILL нельзя поймать, заблокировать или обработать — ядро уничтожает процесс немедленно.

Так что весь твой graceful shutdown — дренаж, закрытие, выход — должен уместиться в этот grace period, минус то, что уже съел preStop hook. Grace period — не предложение; это жёсткий дедлайн, обеспеченный непойманным сигналом.

SIGTERM против SIGKILL

Эти два сигнала — не два вкуса одного; они категорически разные. SIGTERM (сигнал 15) — это запрос: он прерывает процесс и запускает обработчик, который ты зарегистрировал, давая шанс дренировать и прибраться. SIGKILL (сигнал 9) — это команда ядру, а не твоему процессу: он никогда не доставляется твоему коду, так что нет обработчика, нет уборки, нет финального сброса. Вся игра в том, чтобы сделать уборку во время SIGTERM, чтобы SIGKILL вообще не сработал — если SIGKILL срабатывает, ты уже потерял работу в полёте, ровно как в случае резкого выхода из урока один.

Ловушка PID 1

Внутри контейнера первый запущенный процесс становится PID 1, и PID 1 особенный: это процесс, которому оркестратор шлёт сигнал, и ядро даёт ему необычную сигнальную семантику. Две ловушки следом:

• Сигналы идут только в PID 1. Если ты запускаешь приложение как дочерний процесс шелла — sh -c "node server.js" или ничего не подозревающий entrypoint-скрипт — то шелл — это PID 1, SIGTERM доставляется шеллу, а многие шеллы не пробрасывают его детям. Твоё приложение никогда не видит сигнал, ничего не дренирует и получает SIGKILL на дедлайне. Фикс — сделать приложение PID 1 (exec-форма: CMD ["node", "server.js"], или exec node server.js в конце скрипта) или запустить крошечный init вроде tini, который пробрасывает сигналы и пожинает зомби.
• У PID 1 нет дефолтных обработчиков сигналов. Обычно ядро ставит дефолтные действия (вроде «завершиться по SIGTERM»), но для PID 1 оно этого не делает. Если твоё приложение — PID 1, и ты забыл зарегистрировать обработчик, дефолт — игнорировать сигнал, так что процесс продолжает работать и, опять же, ест SIGKILL.