Можно ли проигнорировать sigkill?

Можно ли игнорировать SIGKILL?

Нет, сигнал SIGKILL (сигнал номер 9) проигнорировать или перехватить невозможно. Это фундаментальное свойство ядра операционных систем семейства Unix/Linux, и вот почему.

Техническая суть SIGKILL

SIGKILL — это сигнал безусловного завершения процесса. Его ключевые характеристики:

• Номер сигнала: 9.
• Поведение по умолчанию: Немедленное завершение процесса.
• Возможность обработки: Невозможно ни перехватить (signal, sigaction), ни игнорировать (SIG_IGN).

Попытка сделать это в коде приведёт к ошибке. Вот наглядный пример на C:

#include <stdio.h>
#include <signal.h>
#include <unistd.h>

int main() {
    // Попытка игнорировать SIGKILL - НЕ СРАБОТАЕТ
    if (signal(SIGKILL, SIG_IGN) == SIG_ERR) {
        perror("signal failed for SIGKILL");
    }

    // Попытка установить обработчик для SIGKILL - НЕ СРАБОТАЕТ
    if (signal(SIGKILL, [](int) {
        printf("Это сообщение никогда не будет выведено!\n");
    }) == SIG_ERR) {
        perror("signal handler setup failed for SIGKILL");
    }

    printf("PID: %d\n", getpid());
    printf("Попробуйте выполнить 'kill -9 %d'\n", getpid());

    // Бесконечный цикл для демонстрации
    while(1) {
        pause(); // Ожидание любого сигнала
    }
    return 0;
}

При выполнении этой программы и последующей команды kill -9 <PID> процесс будет немедленно и безусловно завершён, несмотря на все попытки установить обработчик.

Почему это так устроено? Принципиальная причина

SIGKILL является механизмом последней инстанции (fail-safe) для операционной системы. Его главное предназначение — гарантированно завершить процесс, который:

• Завис и не реагирует на другие сигналы (например, SIGTERM).
• Повреждён или ведёт себя деструктивно (например, бесконечный цикл, потребляющий 100% CPU).
• Необходимо остановить для перезагрузки системы или освобождения критических ресурсов.

Если бы можно было перехватить SIGKILL, процесс-злоумышленник мог бы написать собственный обработчик и стать неубиваемым (unkillable), что привело бы к полной нестабильности системы. Ядро резервирует за собой исключительное право на принудительное завершение любого пользовательского процесса.

Сравнение с SIGTERM и SIGSTOP

Для понимания контекста полезно сравнить SIGKILL с другими управляющими сигналами:

• SIGTERM (15): Сигнал корректного завершения. Процесс может и должен его перехватить, чтобы выполнить необходимые процедуры перед выходом: закрыть файлы, завершить сетевые соединения, сохранить состояние. Это сигнал, который отправляет kill по умолчанию.

  kill <PID>          # Отправляет SIGTERM
  kill -15 <PID>      # То же самое
  

• SIGSTOP (19): Сигнал приостановки выполнения. Как и SIGKILL, его нельзя перехватить или игнорировать. Он немедленно останавливает процесс, переводя его в состояние "остановлен" (TASK_STOPPED). Позже его можно возобновить сигналом SIGCONT. Это основа работы job control в shell (Ctrl+Z).

Практическое значение для DevOps/SRE

Понимание этого различия критично для построения надёжных систем:

1. Сценарии завершения: В скриптах оркестрации (Kubernetes, systemd, Docker) и процедурах graceful shutdown сначала должен отправляться SIGTERM. Только после истечения таймаута (например, terminationGracePeriodSeconds в K8s) — SIGKILL.
2. Разработка приложений: Приложение должно корректно обрабатывать SIGTERM для graceful shutdown. Игнорирование SIGTERM — плохая практика, которая приводит к необходимости использования SIGKILL и потенциальной потере данных.
3. Отладка: Если процесс не реагирует на kill (без параметров), это часто означает, что он либо "завис" в состоянии, когда сигналы не доставляются (например, в состоянии D — uninterruptible sleep, часто из-за проблем с I/O), либо некорректно обрабатывает SIGTERM. В таких случаях kill -9 — единственное решение.

Итог

SIGKILL — это "выключатель" на уровне ядра ОС. Его нельзя обойти, перехватить или проигнорировать на уровне пользовательского процесса. Это намеренное и необходимое ограничение, обеспечивающее стабильность и управляемость всей операционной системы. В арсенале администратора и инженера он должен использоваться как крайняя мера, после исчерпания возможностей "цивилизованного" завершения через SIGTERM.