Жизненный цикл процесса

Каждый новый процесс рождается через fork() — клон родителя.

fork() — это системный вызов, создающий точную копию вызывающего процесса. Дочерний процесс получает:

• Новый PID
• Копию памяти родителя через механизм copy-on-write
• Копии всех открытых файловых дескрипторов
• Тот же счётчик инструкций (оба процесса возобновляются после fork())

fork() возвращается дважды: в родителе — PID дочернего, в дочернем — 0. Так оба процесса знают свою роль.

# Наблюдаем fork в действии: оболочка делает fork для каждой команды
echo $$    # PID текущей оболочки, например 1234

# Оболочка делает fork, затем дочерний exec'ит 'ls'
ls /tmp

# После завершения ls управление возвращается родителю (bash)
# Дочерний процесс больше не существует

Ключевой момент: дочерний не пустой — он клон. Поэтому создание дочернего процесса дёшево: копируются только страницы, которые реально записываются (copy-on-write).

exec() заменяет программный образ дочернего на новый.

После fork() дочерний обычно вызывает один из exec() (execve, execvp и др.). Это заменяет память, код и стек дочернего новой программой. Файловые дескрипторы наследуются, если не помечены close-on-exec.

# strace показывает последовательность fork+exec для любой команды
strace -e trace=execve ls /tmp 2>&1 | head -5
# execve("/usr/bin/ls", ["ls", "/tmp"], 0x... /* env */) = 0
# Ядро заменяет образ процесса на /usr/bin/ls

# Для команды оболочки:
strace -e trace=clone,execve bash -c 'echo hello' 2>&1 | grep -E 'clone|execve'
# clone(...) = <child-pid>       -- это fork()
# execve("/usr/bin/bash", [...]) -- дочерний exec'ит bash с -c echo hello

Оболочка делает это тысячи раз в день. Каждый этап конвейера, каждый подпроцесс, каждая подстановка $(command) — это fork, за которым следует exec.

Состояния процессов: что на самом деле означает колонка STAT в ps.

Каждый процесс в любой момент находится в одном из состояний планировщика:

ps aux
# USER       PID %CPU %MEM    VSZ   RSS TTY      STAT ...
# root         1  0.0  0.2  22596  9320 ?        Ss   ...  ← systemd: спит, лидер сессии
# www-data   987  0.1  1.1 123456 44000 ?        S    ...  ← nginx worker: прерываемый сон
# root       123  0.0  0.0      0     0 ?        D    ...  ← непрерываемое ожидание I/O
# root      3456  0.0  0.0      0     0 ?        Z    ...  ← зомби: завершился, не подобран

# Значения букв STAT:
# R  Running — выполняется или готов к выполнению
# S  Interruptible sleep — ждёт события; может быть разбужен сигналом
# D  Uninterruptible sleep — ждёт I/O; НЕЛЬЗЯ убить, даже SIGKILL
# Z  Zombie — завершился, но родитель ещё не вызвал wait()
# T  Stopped — остановлен (SIGSTOP, Ctrl-Z, или трассируется отладчиком)
# +  Процесс переднего плана
# s  Лидер сессии
# l  Многопоточный

Состояние D удивляет операторов: процесс в D-состоянии не реагирует на kill -9. Он находится внутри операции ядра (обычно I/O) и ядро не прерывает его. Если процесс застрял в D на минуты — проблема в I/O-подсистеме (зависший NFS-mount, умирающий диск), а не в самом процессе.

wait(): родитель должен подобрать дочернего, иначе тот станет зомби.

Когда процесс завершается, ядро сохраняет небольшую запись (код выхода, PID, использование ресурсов) до тех пор, пока родитель не вызовет wait() или waitpid(). Дочерний, который завершился, но не подобран — это зомби (состояние Z).

# Зомби в ps выглядят так:
# 1234 Z+  0:00 [defunct]

# Сколько зомби у тебя сейчас?
ps aux | awk '$8 ~ /Z/ { print $0 }'

# Зомби сами по себе НЕ опасны:
# Они занимают PID-слот и небольшую структуру в ядре — ничего больше.
# Никакого CPU, памяти, файловых дескрипторов.

# Зомби становятся проблемой при их тысячах:
# PID — конечный ресурс (cat /proc/sys/kernel/pid_max)
# Родитель с багом, который никогда не вызывает wait(), накапливает зомби.
# Исправление: починить родителя (или перезапустить), не убивать зомби.

# Найти родителя зомби:
ps -o ppid= -p 1234    # выводит PID родителя

Осиротевшие процессы и PID-пространства имён.

Если родитель завершился, пока его дети ещё работают, дети становятся осиротевшими. Ядро немедленно усыновляет их PID 1 (systemd). PID 1 непрерывно вызывает wait() и сразу подбирает осиротевших зомби.

# Демонстрация усыновления:
bash -c 'sleep 300 & echo "child PID: $!"' &
# Убиваем родительский bash — sleep продолжает работать
sleep 1
pstree -p | grep sleep
# sleep теперь дочерний PID 1 (systemd), а не исходного bash

# Превью PID-пространства имён (мост к контейнерам):
# Контейнер — это (среди прочего) новое PID-пространство имён.
# Внутри него процессы видят PID начиная с 1.
# Первый процесс в пространстве становится его PID 1.
# Если он завершится не подобрав детей — зомби накапливаются.
# Поэтому PID 1 контейнера должен обрабатывать сигналы и вызывать wait() —
# или использовать tiny init.
unshare --pid --fork --mount-proc bash
# Внутри: ps показывает PID 1 = bash, PID 2 = ps