PID 1 и init

PID 1 — предок каждого процесса в системе. Когда ядро завершает собственную инициализацию и выполняет /sbin/init, возникший процесс получает PID 1. Каждый другой процесс — это либо прямой потомок PID 1, либо его наследник. Дерево процессов укоренено здесь.

# Показать полное дерево процессов, начиная с PID 1
pstree -p 1

# Увидеть идентичность PID 1
ps -p 1 -o pid,comm,args

На современных Debian/Ubuntu: 1 systemd /lib/systemd/systemd. На старых системах или в контейнерах с минимальным init: 1 init /sbin/init или даже 1 bash (если запущен с init=/bin/bash).

PID 1 пожинает осиротевшие зомби-процессы — и если не делает это, происходит утечка памяти. Когда процесс завершается, ядро хранит маленькую запись о нём (статус завершения), пока родитель не вызовет wait() для её получения. Эта запись называется зомби. Обычно родитель собирает её сразу. Но если родитель умирает раньше потомка, потомок становится сиротой и получает нового родителя — PID 1. Теперь PID 1 обязан вызвать wait() на нём.

Если PID 1 не вызывает wait() — потому что это наивная оболочка или плохо написанный init — сироты накапливаются как зомби. В конечном счёте таблица PID заполняется и новые процессы создать невозможно. Это реальный режим отказа в Docker-контейнерах, использующих произвольный CMD как PID 1 без правильной пересылки сигналов и пожинания.

# Подсчёт зомби-процессов — ненулевое значение означает, что PID 1 не жнёт
ps aux | awk '$8=="Z"' | wc -l

PID 1 неуязвим к SIGKILL — по дизайну ядра, а не по привилегиям. Обычно SIGKILL (сигнал 9) не может быть перехвачен, заблокирован или проигнорирован никаким процессом. Это безусловный сигнал завершения. Единственное исключение: ядро никогда не доставляет SIGKILL на PID 1. Обоснование простое — если PID 1 умрёт, ядро всё равно не сможет продолжать работу и запаникует. Поэтому ядро защищает PID 1 превентивно.

# Это ничего не делает (даже от root)
sudo kill -9 1

# PID 1 всё ещё может получить SIGTERM (systemd обрабатывает его корректно)
sudo kill -15 1  # systemd интерпретирует это как "запустить kbrequest.target"

Контейнеры — заметное исключение: внутри Docker-контейнера PID 1 можно убить SIGKILL с хоста (через docker kill), потому что ядро хоста рассматривает init контейнера как обычный процесс.

SysV init: последовательные скрипты, нет модели зависимостей. Предшественником systemd был SysV init. Его модель: пронумерованные уровни выполнения (0–6), и для каждого уровня набор shell-скриптов в /etc/rc<N>.d/, запускающих или останавливающих сервисы. Скрипты выполнялись последовательно — один за другим — что означало 60-секундную загрузку даже когда большинство сервисов не зависели друг от друга. Зависимости были неявными: порядок скриптов был единственным механизмом координации. Упавший сервис мог заблокировать всё последующее.

# Управление сервисами в стиле SysV (работает как шим совместимости на Ubuntu)
sudo service nginx start
sudo service nginx status

systemd: параллельная активация с явным графом зависимостей. systemd заменил SysV init, моделируя всё как юниты с объявленными зависимостями. Когда запрашивается multi-user.target, systemd обходит граф зависимостей и параллельно запускает все юниты, чьи зависимости удовлетворены. Сервис, которому нужна только сеть, может запускаться одновременно с сервисом, которому нужен только монтируемый раздел — они не блокируют друг друга.

# Посмотреть, что systemd активировал при последней загрузке и когда
systemd-analyze plot > boot.svg   # генерирует визуальную временную шкалу

# Проверить граф зависимостей для юнита
systemctl list-dependencies sshd.service

# Проверить здоровье PID 1 (systemd)
systemctl is-system-running

Ключевое понимание: systemd превратил неявное упорядочение (номера скриптов) в явный граф (After=, Requires=, Wants=). Вот почему загрузка с systemd быстрее и почему упавший необязательный сервис не останавливает остальную загрузку.