Как убить процесс

Уничтожение процесса в Linux

Убийство процесса — ключевая операция управления системами в DevOps. Это не просто команда, а часть жизненного цикла управления приложениями, мониторинга и обеспечения доступности.

Основные команды и инструменты

1. kill — базовый сигнал

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

# Отправить SIGTERM (по умолчанию)
kill 12345

# Явное указание сигнала
kill -TERM 12345
kill -15 12345

2. kill -9 (SIGKILL) — крайняя мера

Сигнал SIGKILL (9) — принудительное уничтожение. Процесс не может его перехватить или проигнорировать, но это может привести к:

• Утечкам ресурсов
• Повреждению данных
• Неожиданному поведению системы

# Принудительное завершение (опасно!)
kill -9 12345
kill -KILL 12345

3. pkill и killall — убийство по имени

Эти команды идентифицируют процессы по имени, что удобно при неизвестном PID.

# Завершить все процессы с именем "nginx"
pkill nginx
killall nginx

# С определенным сигналом
pkill -TERM python

4. Поиск PID перед убийством

Перед завершением нужно идентифицировать процесс:

# Классический поиск
ps aux | grep nginx

# Современные альтернативы
pgrep nginx
pidof nginx

Стратегия "щадящего" убийства в DevOps

В продакшн-средах мы НИКОГДА не начинаем с kill -9. Используем поэтапный подход:

Этап 1: Graceful Shutdown (SIGTERM)

kill -TERM <PID>

Даем приложению время (30-60 секунд) на корректное завершение: закрытие соединений, сохранение состояния, остановку worker'ов.

Этап 2: Усиленный сигнал (SIGINT/HUP)

kill -INT <PID>
kill -HUP <PID>  # Часто перезагружает конфигурацию

Этап 3: Принудительное завершение (только если необходимо)

# Последнее средство
kill -KILL <PID>

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

Сценарий 1: Зависший воркер Celery/RQ

# 1. Ищем воркеры
ps aux | grep "celery worker"

# 2. Пытаемся мягко завершить
pkill -TERM -f "celery worker"

# 3. Ждем 30 секунд, проверяем
sleep 30
ps aux | grep "celery worker" | grep -v grep

# 4. Если остались - принудительно
if [ $? -eq 0 ]; then
    pkill -KILL -f "celery worker"
fi

Сценарий 2: Остановка Docker-контейнера

# Docker сначала отправляет SIGTERM
docker stop container_name

# Через таймаут (по умолчанию 10s) отправляет SIGKILL
docker kill container_name

Сценарий 3: Автоматизация в скриптах

#!/bin/bash
APP_PID=$(pgrep -f "myapp.py")

if [ -z "$APP_PID" ]; then
    echo "Процесс не найден"
    exit 0
fi

echo "Отправляем SIGTERM процессу $APP_PID"
kill -TERM "$APP_PID"

TIMEOUT=30
while [ $TIMEOUT -gt 0 ]; do
    kill -0 "$APP_PID" 2>/dev/null || break
    sleep 1
    ((TIMEOUT--))
done

if kill -0 "$APP_PID" 2>/dev/null; then
    echo "Таймаут, отправляем SIGKILL"
    kill -KILL "$APP_PID"
fi

Важные нюансы для продакшн

1. Сигналы должны обрабатываться приложением — разработчики должны реализовать корректную обработку SIGTERM
2. Orphaned processes — убийство родительского процесса может оставить "сирот"
3. Zombie processes — уже завершенные процессы, ожидающие родителя
4. Process groups — иногда нужно убивать всю группу: kill -TERM -<PGID>
5. Пользовательские ограничения — проверяйте права (sudo может потребоваться)

Мониторинг и алертинг

В современных DevOps-стэках:

• Prometheus Alertmanager алертит о "зомби"-процессах
• Supervisor/systemd автоматически перезапускают процессы
• Kubernetes использует grace period для pod'ов
• Sentry/Logging фиксируют некорректные завершения

Золотое правило

Всегда начинайте с мягких сигналов, документируйте процедуры завершения для каждого сервиса, и помните — kill -9 это не решение проблемы, а признак того, что архитектура приложения имеет недостатки в обработке состояний.