Что вызывает команда kill: SIGTERM или SIGKILL

Отличный и очень важный вопрос, который затрагивает самую суть корректного завершения процессов в Linux. Ответ не так однозначен, как кажется, и демонстрирует ключевую философию Unix.

Краткий ответ: По умолчанию команда kill отправляет сигнал SIGTERM. Сигнал SIGKILL отправляется явно с помощью опции -9 или -KILL.

---

Подробное объяснение команды kill

Команда kill — это, по сути, интерфейс для отправки сигналов процессам. Её базовый синтаксис:

kill [опции] <PID>

Где <PID> — это идентификатор целевого процесса.

По умолчанию, если не указана ни одна опция, kill отправляет сигнал SIGTERM (сигнал номер 15). Это сигнал "терминации" (termination), который является вежливым запросом на завершение.

kill 1234  # -> Процессу с PID 1234 отправляется SIGTERM (15)

Как отправить SIGKILL?

Чтобы отправить сигнал SIGKILL (сигнал номер 9), который является безусловным, немедленным убийством процесса, необходимо указать его явно. Это можно сделать несколькими способами:

1. Используя номер сигнала (-9):

   kill -9 1234
   

2. Используя имя сигнала (без префикса SIG):

   kill -KILL 1234
   

    или

```bash
kill -SIGKILL 1234  # Также работает
```

Ключевое различие между SIGTERM и SIGKILL

Это различие — основа грамотного администрирования и написания устойчивых приложений.

SIGTERM (Вежливый запрос)

• Цель: Дать процессу возможность корректно завершиться.
• Поведение: Процесс-получатель:

    *   **Перехватывает сигнал** (может иметь свой `signal handler`).
    *   Выполняет процедуры graceful shutdown:
        *   Закрывает открытые файлы и сетевые соединения.
        *   Сохраняет состояние (дамп памяти, фиксация транзакций БД).
        *   Уведомляет дочерние процессы.
        *   После этого **самостоятельно завершает свою работу**.

• Использование: Стандартный способ остановки сервисов (например, systemctl stop nginx сначала шлет SIGTERM).

SIGKILL (Немедленное убийство)

• Цель: Немедленно прекратить выполнение процесса любой ценой.
• Поведение:

    *   **НЕ МОЖЕТ быть перехвачен, обработан или проигнорирован** процессом. Ядро ОС останавливает процесс напрямую.
    *   Процесс не успевает выполнить никаких очищающих действий.
    *   Это может привести к:
        *   Повреждению файлов (если шел процесс записи).
        *   "Висячим" сокетам и блокировкам.
        *   Потере данных в памяти.
        *   Появлению "зомби"-процессов (если не обработаны дочерние процессы).

• Использование: Крайняя мера, когда процесс не реагирует на SIGTERM (завис, имеет баг в обработчике сигналов).

Практические примеры и рекомендации

Правильный подход к остановке процесса (паттерн):

1. Попробуйте вежливо остановить сервис через его менеджер:

   sudo systemctl stop myapp
   

2. Если это не работает, найдите PID и отправьте SIGTERM:

   ps aux | grep myapp
   kill <PID>  # Или kill -15 <PID>
   

3. Дайте процессу время (таймаут, например, 30 секунд) на выполнение cleanup-процедур.
4. Только если процесс все еще жив, используйте SIGKILL:

   kill -9 <PID>
   

Важное замечание в контексте DevOps и контейнеризации: В Docker/Kubernetes этот паттерн формализован. При остановке контейнера (docker stop, kubectl delete pod) сначала отправляется SIGTERM, и только после grace period (по умолчанию 30s в Kubernetes) отправляется SIGKILL. Это критично для stateful-приложений (БД, очереди сообщений), чтобы гарантировать целостность данных.

# Пример спецификации Pod в Kubernetes
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: myapp
    image: myapp:latest
    lifecycle:
      preStop: # Хук, выполняемый ДО отправки SIGTERM
        exec:
          command: ["/bin/sh", "-c", "echo 'Начинаем graceful shutdown'"]
    terminationGracePeriodSeconds: 60 # Время на завершение после SIGTERM

Вывод

Итак, kill по умолчанию шлет SIGTERM, а kill -9 — SIGKILL. Понимание этой разницы — не просто знание синтаксиса, а понимание философии управления процессами в Unix. SIGTERM — это инструмент для штатного, безопасного завершения. SIGKILL — это "аварийный выключатель", использование которого без необходимости является признаком проблем в дизайне приложения или процедурах администрирования. Хороший DevOps-инженер всегда стремится дать процессам шанс завершиться правильно, прежде чем прибегать к силе.