Почему процесс-зомби не занимает ни байта памяти, но может положить сервер

MAATRIX

Вы смотрите в top, видите строку со статусом Z и колонкой памяти в ноль, и первая реакция — «ну и ладно, раз он ничего не жрёт». А через месяц сервер отказывается принимать новые соединения, fork() в логах падает с Resource temporarily unavailable, и оказывается, что зомби были не безобидным мусором, а симптомом медленно текущей утечки другого рода — утечки записей в таблице процессов. Разберём, что происходит с процессом после его смерти, почему он действительно не занимает память, и почему это не отменяет реальной опасности.

Что такое процесс-зомби на самом деле

Когда процесс завершается — вызывает exit(), получает необработанный сигнал или просто доходит до конца main(), — ядро Linux не удаляет его немедленно. Происходит следующее:

1. Ядро закрывает все файловые дескрипторы процесса, освобождает виртуальную память, отключает от него разделяемые библиотеки, снимает с очередей планировщика.
2. Ядро сохраняет код возврата (exit code), статистику использования CPU и другую итоговую информацию в компактной записи процесса.
3. Процесс переходит в состояние Z (zombie, в выводе ps часто помечается как defunct) и ждёт, пока родительский процесс заберёт эту информацию через системный вызов wait() или waitpid().
4. Только после того, как родитель вызвал wait(), ядро удаляет последнюю запись из таблицы процессов (process table), и PID полностью освобождается.

То есть зомби — это не «мёртвый, но работающий» процесс. Это уже полностью мёртвый процесс, от которого осталась ровно одна структура данных в ядре: task_struct в сильно урезанном виде. Именно поэтому в top и htop у зомби всегда 0.0% CPU и 0 памяти в столбцах RSS/VSZ — измерять там нечего, вся адресная память давно возвращена системе.

Проверить состояние конкретного процесса можно напрямую:

cat /proc/<pid>/status | grep State

Для зомби вы увидите State: Z (zombie). А список всех зомби в системе — одной командой:

ps -eo pid,ppid,stat,cmd | awk '$3 ~ /Z/'

Почему зомби не расходует ни память, ни CPU — разбираем парадокс

Кажущийся парадокс в том, что интуитивно «процесс, который висит в списке процессов, что-то же должен занимать». На самом деле разница принципиальная между двумя вещами:

• Ресурсы самого процесса (адресное пространство, кучи, стек, открытые файлы, сокеты) — освобождаются в момент завершения, до перехода в состояние зомби. Это происходит всегда, вне зависимости от того, вызовет родитель wait() или нет.
• Запись в таблице процессов — крошечная структура (в современных ядрах это часть task_struct, урезанная до идентификатора, кода возврата и статистики) — остаётся, потому что она нужна родителю. Ядро не может знать заранее, важен ли код возврата вызывающей стороне, поэтому обязано сохранить его до явного запроса.

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

Кто должен «похоронить» зомби: роль родителя и wait()

За уборку зомби отвечает родительский процесс, и происходит это так:

1. Дочерний процесс завершается, ядро посылает родителю сигнал SIGCHLD.
2. Родитель либо явно вызывает wait()/waitpid() в обработчике SIGCHLD, либо периодически опрашивает статус детей.
3. После вызова wait() ядро окончательно уничтожает запись зомби и освобождает PID для повторного использования.

Если родитель это делает — зомби живёт доли секунды и в ps вы его просто не увидите. Проблема начинается, если родитель:

• не подписан на SIGCHLD и никогда не вызывает wait() (типичная ошибка в самописных демонах и скриптах-обёртках, которые запускают дочерние процессы через fork()/exec() и забывают про них);
• завис, упал в состояние D (непрерываемый сон на I/O) или заблокирован сам — тогда он физически не может обработать SIGCHLD, даже если хотел бы;
• сам стал зомби или завершился раньше своих детей без корректной передачи их системному init.

Отдельный случай — если сам родитель уже умер до того, как забрал детей. Тогда осиротевшие процессы (и будущие зомби) переусыновляются процессом с PID 1 (init, systemd или, в контейнере, тем, что запущено как PID 1). У PID 1 есть особая обязанность в ядре — периодически вызывать wait() за всех осиротевших детей именно для того, чтобы зомби не копились вечно. Если PID 1 в контейнере — это ваше приложение (например, Node.js или Python-скрипт), которое само не занимается reaping, эта защита не работает, и мы подробно разбирали похожий сценарий в статье про то, как PID 1 не пересылал сигналы и ронял деплой — тот же класс проблемы: init-процесс не выполняет свои обязанности перед детьми.

Как накопление зомби реально кладёт сервер

Вот та часть, где кажущаяся безобидность оборачивается инцидентом. У ядра Linux есть жёсткий предел на общее число процессов и на диапазон PID:

cat /proc/sys/kernel/pid_max
sysctl kernel.pid_max

Каждый зомби — это ровно один занятый PID и один занятый слот в таблице процессов, до тех пор, пока родитель его не заберёт. Если родитель систематически не делает wait() — например, плодит новые дочерние процессы в цикле (обработка входящих соединений, запуск воркеров, вызов внешних утилит через system()/popen()), — зомби накапливаются один за другим и никогда не освобождаются сами по себе. Занятые PID не переиспользуются, пока запись зомби жива.

Дальше срабатывает цепочка:

• Число процессов приближается к kernel.pid_max (или к лимиту ulimit -u для конкретного пользователя, если он ниже системного).
• Новые вызовы fork() начинают завершаться ошибкой EAGAIN — «Resource temporarily unavailable», причём ошибка эта не про память и не про CPU, а именно про невозможность выделить новый PID.
• Любой сервис, которому нужно породить дочерний процесс — веб-сервер, принимающий новое соединение через fork-модель, cron, ssh, shell-обёртки, — начинает падать с этой же ошибкой.
• В худшем случае система вообще перестаёт запускать новые процессы, включая диагностические (ps, top, bash), потому что и они требуют fork().

Здесь стоит явно развести две смежные, но разные аварии, чтобы не путать их в логах:

• Исчерпание PID/таблицы процессов из-за зомби — симптом: fork failed: Resource temporarily unavailable, при этом свободной памяти по free -h может быть много.
• Исчерпание лимита пользователя на число процессов (ulimit -u, nproc) — похожий симптом, но причина не в зомби, а в общем количестве живых процессов пользователя; мы разбирали этот сценарий отдельно в статье про то, как лимит процессов на пользователя оборвал деплой.

Оба случая внешне выглядят как «сервер завис», но требуют разной диагностики: в первом случае вы увидите десятки или сотни строк со статусом Z в ps, во втором — живые процессы, упирающиеся в ulimit.

Практические примеры: где зомби реально накапливаются

Несколько сценариев, которые на практике встречаются чаще всего:

Веб-приложение или CGI-скрипт, вызывающий внешние утилиты. Код вида subprocess.Popen(...) в Python или exec()/system() в PHP без последующего ожидания результата — классический источник зомби при высокой частоте запросов. Если на каждый HTTP-запрос происходит один такой вызов без wait(), а сервис не перезапускается, зомби копятся пропорционально трафику.

Docker-контейнер без нормального init-процесса. Если приложение в контейнере запущено напрямую как PID 1 (без tini, dumb-init или --init), а оно порождает дочерние процессы (например, воркеры, cron-подобные задачи, обёртки над CLI-утилитами) и не реализует reaping, зомби накапливаются именно внутри пространства имён контейнера. Проверить это можно так:

docker top <container_id> | grep Z

Лечится флагом --init при запуске (docker run --init ...) или явным указанием tini как entrypoint — тогда PID 1 берёт на себя обязанность вызывать wait() за все процессы в контейнере.

Самописные демоны и супервизоры. Скрипт, который в цикле форкает воркеров для обработки очереди задач, но обрабатывает только успешное завершение и забывает про ветку с ошибкой, — оставляет зомби именно в ветке исключений. Это медленная утечка: система может работать неделями, прежде чем накопленных зомби станет достаточно, чтобы упереться в лимит.

Fork-бомба или баг с бесконечным циклом порождения процессов. Отдельный, гораздо более быстрый сценарий: если код (по ошибке или в результате атаки) вызывает fork() в цикле без ограничения, таблица процессов заполняется не зомби, а живыми процессами — тоже в считаные секунды упирается в pid_max. Симптомы на уровне ошибок идентичны исчерпанию PID из-за зомби, но причина другая, и ps в этом случае покажет живые процессы, а не Z.

Диагностика и лечение на живом сервере

Порядок действий, когда вы подозреваете накопление зомби:

# посчитать зомби
ps -eo stat | grep -c Z

# найти зомби с их родителями
ps -eo pid,ppid,stat,cmd | awk '$3 ~ /Z/'

# посмотреть, сколько всего процессов и какой лимит
ps -e | wc -l
cat /proc/sys/kernel/pid_max
ulimit -u

Если зомби нашлись — искать нужно не сам зомби (убить Z-процесс сигналом нельзя, он уже мёртв и ни на какие сигналы не реагирует), а его родителя из колонки PPID:

ps -p <PPID> -o pid,cmd,stat

Дальше два пути:

• Если родитель жив, но завис или не обрабатывает SIGCHLD — перезапустить именно его (не весь сервер). После завершения родителя все его зомби-дети переусыновляются init/systemd, который корректно вызовет wait() и уберёт их за секунды.
• Если родитель сам в состоянии D (непрерываемый сон) — это отдельная и более тяжёлая проблема с I/O, которая требует своей диагностики; зомби здесь — следствие, а не причина.

Профилактика на уровне архитектуры:

• В коде, который явно вызывает fork(), всегда регистрировать обработчик SIGCHLD с вызовом waitpid(-1, NULL, WNOHANG) в цикле, либо использовать библиотечные обёртки, которые это делают за вас (например, модуль subprocess в Python с корректным communicate()/wait(), а не «выстрелил и забыл»).
• В контейнерах — всегда запускать реальный init-процесс как PID 1 (tini, dumb-init, docker run --init), особенно если внутри контейнера порождаются дочерние процессы.
• Мониторить количество зомби как отдельную метрику, а не полагаться на общий мониторинг памяти — метрика по CPU/RAM зомби не покажет никак, а вот число процессов в состоянии Z и близость к pid_max — вполне измеримые и алертуемые величины. Общие принципы сбора метрик по загрузке и процессам разобраны в статье про поиск причины высокой нагрузки на процессор.
• Если у вас на сервере systemd — он сам является PID 1 для системных сервисов и корректно реапит зомби от юнитов, которые запускает напрямую; но если сервис сам порождает собственных потомков через fork, ответственность за них всё равно на самом сервисе, а не на systemd. Подробнее о том, как systemd ведёт себя как init-процесс при загрузке, — в статье как работает systemd при загрузке.

Частые вопросы