Есть ли сигнал, который нельзя обработать

Краткий ответ

Да, есть несколько типов сигналов, которые нельзя обработать, перехватить или проигнорировать стандартными средствами POSIX. Это так называемые необрабатываемые (uncatchable) или фатальные сигналы. Их основная цель — немедленное и гарантированное завершение процесса.

Необрабатываемые сигналы в Linux/Unix

1. SIGKILL (сигнал 9)

Это самый известный необрабатываемый сигнал. Ядро операционной системы гарантирует завершение процесса, получившего SIGKILL. Любая попытка установить обработчик (через signal() или sigaction()) будет проигнорирована системой.

#include <signal.h>
// Этот код НЕ сработает для SIGKILL
signal(SIGKILL, my_handler); // Функция my_handler никогда не будет вызвана

2. SIGSTOP (сигнал 19)

Сигнал приостановки выполнения процесса. Аналогично SIGKILL, его нельзя перехватить, блокировать или проигнорировать. Он немедленно останавливает процесс, переводя его в состояние TASK_STOPPED.

Почему эти сигналы нельзя обработать?

Это дизайнерское решение ядра ОС, обеспечивающее два критических сценария:

• Средство "последней надежды" для администратора: SIGKILL позволяет гарантированно "убить" зависший, вышедший из-под контроля или зловредный процесс, который мог бы установить обработчики на все другие сигналы.
• Контроль со стороны супервизора: SIGSTOP позволяет оболочке или менеджеру процессов (например, bash с Ctrl+Z) безусловно приостановить задачу для управления заданиями.

Что насчёт SIGTERM и других сигналов?

В отличие от SIGKILL, большинство других сигналов (SIGTERM, SIGINT, SIGHUP и др.) можно и нужно обрабатывать. Это основа корректного завершения работы приложений.

# SIGTERM (15) может быть обработан программой для graceful shutdown
kill -TERM <pid>
# SIGKILL (9) НЕ может быть обработан, завершает немедленно
kill -KILL <pid>
# Или его короткий аналог
kill -9 <pid>

Примеры в инфраструктуре и оркестрации

В контексте Kubernetes и Docker это различие критически важно:

• docker stop отправляет SIGTERM, затем ждёт таймаут (--time), и только потом отправляет SIGKILL.
• docker kill по умолчанию отправляет SIGKILL, но может отправлять и другие сигналы (например, docker kill --signal=SIGTERM).
• В Kubernetes при удалении Pod'а сначала отправляется SIGTERM (согласно terminationGracePeriodSeconds), а затем SIGKILL.

Важное исключение: В некоторых специализированных или виртуализированных средах (например, процессы в отдельных пространствах имён Linux или контейнерах без привилегий) даже SIGKILL может быть "перехвачен" гипервизором или монитором более высокого уровня для эмуляции или логирования. Но с точки зрения самого процесса внутри пространства имён PID — сигнал остаётся необрабатываемым.

Итог

SIGKILL и SIGSTOP — единственные два сигнала в стандарте POSIX, которые абсолютно необрабатываемы с точки зрения процесса-получателя. Это архитектурный механизм безопасности и контроля. Для всех остальных сигналов процесс может:

• Установить собственный обработчик.
• Проигнорировать их (кроме SIGKILL и SIGSTOP).
• Использовать действие по умолчанию.

Понимание этого различия — ключевой навык для DevOps/SRE-инженера, так как оно напрямую влияет на стратегии graceful shutdown, отказоустойчивости и управления жизненным циклом приложений в production-средах.