Что такое процесс зомби

Зомби процессы Linux

Каждая программа, которая выполняется в Linux, — это системный процесс, у которого есть свой идентификатор. Каждый процесс может запускать дочерние процессы с помощью функции fork. Такие процессы остаются под контролем родительского процесса и не могут быть завершены без его ведома. Если один из дочерних процессов всё же завершился, а его родительский процесс не смог получить об этом информацию, то такой дочерний процесс становится зомби.

Зомби процессы Linux не выполняются и убить их нельзя, даже с помощью sigkill, они продолжают висеть в памяти, пока не будет завершён их родительский процесс.

Посмотреть такие процессы можно с помощью утилиты ps, здесь они отмечаются как defunct:

ps aux | grep defunct

Если вы попытаетесь убить такой процесс с помощью сигнала KILL, то ничего не выйдет:

Чтобы его завершить, нужно найти «родителя» этого процесса. Для этого используйте команду:

ps -xal | grep defunct

Здесь идентификатор родительского процесса находится в четвёртой колонке (PPID). Теперь мы можем послать ему сигнал завершения, и такого процесса в системе больше не будет:

Для большего удобства вы можете использовать утилиты top или htop, но принцип их действия будет аналогичным, поэтому я не буду здесь его рассматривать. Теперь вы знаете, что делать, если в вашей системе появились зомби процессы Linux.

Зомби-процесс

Проце́сс-зо́мби, зо́мби (англ. zombie process , англ. defunct process ) — дочерний процесс в Unix-системе, завершивший своё выполнение, но еще присутствующий в списке процессов операционной системы, чтобы дать родительскому процессу считать код завершения.

Содержание

Этимология

Происходит от слова «зомби», означающего «живой мертвец» (оксюморон, англ. undead ). Термин является яркой метафорой о том, что процесс «умер», но не «погребён».

Возникновение зомби

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

Система уведомляет родительский процесс о завершении дочернего с помощью сигнала SIGCHLD он считает код возврата с помощью системного вызова wait() , после чего запись зомби будет удалена из списка процессов.

Если родительский процесс игнорирует SIGCHLD (а он игнорируется по умолчанию), то зомби остаются до его завершения.

Проблемы зомби

Зомби не занимают памяти (как процессы-сироты), но блокируют записи в таблице процессов, размер которой ограничен для каждого пользователя и системы в целом.

При достижении лимита пользователь, от имени которого выполняется программа, и все его программы не будут способны создавать новые дочерние процессы. Кроме всего прочего пользователь, от имени которого выполняется родительский процесс, не сможет зайти на консоль (локальную или удаленную) или выполнить какие-либо команды на уже открытой консоли (потому что для этого командный интерпретатор sh должен создать новый процесс), и для восстановления работоспособности (завершения виновной программы) будет необходимо вмешательство системного администратора.

Если же процесс выполнялся от имени суперпользователя, то проблему может решить только перезагрузка (причем зачастую — только аппаратным рестартом). Некоторые операционные системы (например, Sun Solaris) при возникновении такой ситуации аварийно завершают часть выполняющихся процессов, восстанавливая работоспособность системы. Одна из компьютерных баек утверждает, что Solaris может таким образом аварийно завершить выполнение корневого родительского процесса

Примеры программ, создающих зомби, на разных языках программирования

Разное

Зомби не могут принимать сигналы, и поэтому их нельзя убрать с помощью утилиты или вызова kill. Убрать их может либо родительский процесс, либо его завершение.(см.прим.
Все процессы в Unix имеют своих родителей — процессы, не имеющие или потерявшие родителей («осиротевшие» процессы; англ.orphan process ), являются дочерними для
Зомби можно узнать в списке процессов (выводимых утилитой ps) по флагу «Z» в колонке STAT.
Хорошим стилем программирования считается всегда обрабатывать SIGCHLD.
Языки скриптов Python неявно обрабатывают SIGCHLD, если программа настраивает его игнорирование.

См. также

Процесс-сирота

Wikimedia Foundation . 2010 .

Полезное

Смотреть что такое «Зомби-процесс» в других словарях:

Процесс-зомби — Процесс зомби, зомби (англ. zombie process, англ. defunct process) дочерний процесс в Unix системе, завершивший своё выполнение, но ещё присутствующий в списке процессов операционной системы, чтобы дать родительскому процессу… … Википедия

Процесс-сирота — (англ. orphan process) в семействе операционных систем UNIX вспомогательный процесс, чей основной процесс (или связь с ним) был завершен нештатно (не подав сигнала на завершение работы). Обычно, «сиротой» остается дочерний процесс… … Википедия

Зомби — У этого термина существуют и другие значения, см. Зомби (значения). В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнен … Википедия

Зомби (значения) — Зомби: Зомби оживший мертвец, не способный мыслить, существующий только для того, чтобы исполнять приказы своего создателя Зомбирование применение манипулятивных методов при попытке изменить мышление, поведение, верования, эмоции или… … Википедия

Порошок зомби — Рыцарь печального образа у диких островных негров Зомби (от банту конголезского «nzambi» «бог») в общем случае обозначение живого человека, полностью потерявшего контроль над собой и своим телом и подчиняющимся чьим то приказам (будь то в… … Википедия

Образ зомби в искусстве — Эта статья предлагается к удалению. Пояснение причин и соответствующее обсуждение вы можете найти на странице Википедия:К удалению/15 ноября 2012. Пока процесс обсуждения не завершён, статью можно … Википедия

Zombie — Процесс зомби, зомби (англ. zombie process, англ. defunct process) дочерний процесс в Unix системе, завершивший своё выполнение, но еще присутствующий в списке процессов операционной системы, чтобы дать родительскому процессу считать код… … Википедия

Call of Duty: Black Ops II — Call of Duty: Black Ops 2 Разработчик … Википедия

Plants vs. Zombies — Разработчик PopCap Games Издатель … Википедия

Resident Evil 2 — Обложка ПК издания игры Разработчик … Википедия

Зомби, которые съедают вашу память

Что бы вы там себе не думали, а зомби существуют. И они действительно едят мозги. Не человеческие, правда, а компьютерные. Я говорю сейчас о зомби-процессах и потребляемых ими ресурсах. Это будет душераздирающая история о потерянных и снова найденных 32 ГБ оперативной памяти. Возможно, лишь некоторые из вас столкнутся с точно такой же проблемой, но если вдруг это произойдёт — у вас хотя бы будет шанс понять, что происходит.

Начнём с того, что компьютеры под управлением ОС Windows склонны со временем терять память. Ну, по крайней мере, у меня, при моём способе ими пользоваться. После пары недель без перезагрузок (или, например, всего одного уикэнда за который я 300 раз пересобрал Хром) я стал замечать, что диспетчер задач начинает показывать мне очень маленькое количество свободной оперативной памяти, но в то же время в системе нет никаких процессов, которые эту самую память активно используют. В том примере выше (с 300 сборками Хрома) диспетчер задач сказал мне, что в системе занято 49.8 ГБ плюс ещё 4.4 ГБ памяти сжато — но при этом запущено всего несколько процессов, и все они в сумме даже и близко не используют столько памяти:

В моём компьютере 96 ГБ оперативной памяти (да, я счастливчик) и когда у меня нет вообще никаких запущенных процессов — я, знаете ли, хотел бы видеть ну хотя бы половину этой памяти свободной. Я правда рассчитываю на это. Но иногда этого достичь не удаётся и мне приходится перезагружать ОС. Ядро Windows написано качественно и надёжно (без шуток), так что память не должна бы пропадать бесследно. Но всё же она пропадает.

Первой же моей догадкой стало воспоминание о том, что один из моих коллег как-то жаловался на зомби-процессы, которые иногда остаются в ОС уже не активными, но всё же ещё не до конца удалёнными ядром. Он даже написал специальную утилиту, которая выводит список таких процессов — их имена и количество. Когда он запускал эту утилиту в своих тестах, то получал до нескольких сотен зомби-процессов на обычной Windows-машине. Я нашел его инструмент, запустил на своём компьютере и получил… 506 000 зомби-процессов. Да, 506 тысяч!

Я вспомнил, что одной из возможных причин перехода процесса в состояние «зомби» может быть то, что какой-то другой процесс держит открытым его дескриптор (handle). В моём случае большое количество зомби-процессов играло мне на руку — им было сложнее скрыться. Я просто открыл диспетчер задач и добавил на вкладку Details столбец с количеством открытых дескрипторов для каждого процесса. Затем отсортировал список по убыванию значений в этом столбце. Я сразу нашел героя данной истории — процесс CcmExec.exe (часть Microsoft System Management Server) имел 508 000 открытых дескрипторов. Это было во-первых, очень много, а во-вторых, подозрительно близко к найдненному мною выше числу в 506 000 зомби-процессов.

Я убил процесс CcmExec.exe и получил следующий результат:

Всё получилось ровно так, как я того и ожидал. Как я без иронии писал выше — ядро Windows написано очень хорошо и когда процесс уничтожается, то и все занятые им ресурсы освобождаются. Закрытие CcmExec.exe освободило 508 000 дескрипторов, что дало возможность окончательно закрыть 506 000 зомби-процессов. Количество свободной оперативной памяти мгновенно выросло на 32 ГБ. Тайна раскрыта!

Что такое зомби-процесс?

До этого момента мы ещё не выяснили, что же заставило все эти процессы зависнуть в неопределённости, а не быть удалёнными. Похоже на то, что мы имеем дело с тривиальным багом в приложении (а не в ядре ОС). Общее правило гласит, что когда вы создаёте процесс, то получаете его дескриптор и дескриптор его главного потока. Вы ОБЯЗАНЫ закрыть эти дескрипторы. Если вашей задачей было просто запустить процесс — их можно закрыть сразу же (это не убъёт запущенный процесс, а просто разорвёт связь вашего процесса с ним). Если новый процесс вам для чего-то нужен (например, вы ждёте окончания его работы или вам нужен код, который он вернёт) — то нужно воспользоваться соответствующими функциями (например, WaitForSingleObject(hProcess, INFINITE) для ожидания выхода или GetExitCodeProcess(hProcess, &exitCode) для получения кода возврата) и всё-равно закрыть дескрипторы после того, как вы получили от дочернего процесса всё, чего хотели. Аналогично следует и поступать и с дескрипторами процессов, которые вы для чего-нибудь открываете с помощью функции OpenProcess().

Если процесс, который забывает так поступать, относится к системным, то вам даже может не помочь выйти из своего аккаунта и снова залогиниться, только полная перезагрузка.

Куда же девается память?

500 000 раз по 32 КБ будет равно примерно 16 ГБ — куда же делась остальная память? Сравнение состояния памяти до и после закрытия зомби-процессов даёт ответ на этот вопрос:

Мы можем чётко увидеть, что

16 ГБ уходит на Process Private Memory. Также мы видит, что ещё 16 ГБ приходится на Page Table Memory. Очевидно, что каждый зомби-процесс занимает 32 КБ в таблице страниц памяти и еще 32 КБ использует для своей личной памяти. Я не знаю для чего зомби-процессу так много памяти, но, наверное, никто никогда не думал, что число таких процессов может измеряться сотнями тысяч.

Некоторые типы занятой памяти увеличились после закрытия процесса CcmExec.exe, в основном это касается Mapped File и Metafile. Я не знаю точно, почему так получилось. Одной из моих догадок является то, что ОС решила, что свободной памяти теперь достаточно и что-то себе закешировала. Это, в общем, не плохо. Мне не жаль памяти для нужд ОС, я просто не хочу, чтобы она пропадала совсем уж бесцельно.

Важное замечание: RamMap тоже открывает дескрипторы всех процессов, так что эту утилиту следует закрыть, если вы хотите добиться закрытия зомби-процессов.

Я написал твит о моей находке и исследование продолжил другой программист, который сумел воспроизвести данный баг и передать информацию о нём разработчику из Microsoft, который сказал, что это «известная проблема, которая иногда случается, когда очень много процессов запускаются и закрываются очень быстро».

Я надеюсь, что данная проблема будет скоро исправлена.

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

Я работаю над кодом Windows-версии Хрома и одной из моих задач является оптимизация его сборки на этой ОС, а это требует многократных запусков этой самой сборки. Каждая сборка Хрома запускает огромное множество процессов — от 28 000 до 37 000 в зависимости от выбранных настроек. При использовании нашей распределённой системы сборки (goma) эти процессы создаются и закрываются очень быстро. Мой лучший результат сборки Хрома — 200 секунд. Но столь агрессивная политика запуска процессов выявляет и проблемы в ядре Windows и её компонентах:

Быстрое удаление процессов ведёт к зависаниям пользовательского ввода
Драйвер тачпада выделяет, но не освобождает память при каждом создании процесса
App Verifier создаёт O(n^2) лог-файлов (и об этом стоит написать отдельный пост!)
Есть баг в ядре Windows, который касается буферизации файлов, и этот баг воспроизводится на всех Windows от Server 2008 R2 до Windows 10
Windows Defender задерживает запуск каждого процесса goma на 250 мс

Что дальше?

Если вы работаете не на компьютере, управляемом политиками компании, то процесс CmmExec.exe у вас не запущен и с конкретно данным багом вы не столкнётесь. Также он коснётся вас только если вы собираете Хром или делаете ещё что-то похожее, создавая и закрывая при этом десятки тысяч процессов в короткие промежутки времени.

CcmExec — не единственная в мире программа с багами. Я нашел много других, содержащих в себе конкретно этот же тип ошибок, приводящих к созданию зомби-процессов. И есть ещё огромное множество тех, которые я не нашел.

Как знают все опытные программисты, любая ошибка, которая не была явно исправлена или предупреждена — точно когда-то произойдёт. Просто написать в документации «Пожалуйста, закройте этот дескриптор» — не достаточно. Так что вот мой вклад в то, чтобы сделать нахождение подобного типа ошибок проще, а их исправление — реальнее. FindZombieHandles — это инструмент, основанный на NtApiDotNet и коде от @tiraniddo, который выводит список зомби-процессов и информацию о том, кто сделал их зомби. Вот пример вывода данной утилиты, запущенной на моём компьютере:

274 зомби — это ещё не так плохо. Но уже и это указывает на определённые проблемы, которые могут быть найденны и исправлены. Процесс IntelCpHeciSvc.exe в этом списке имеет самые большие проблемы — похоже на то, что он открывает (и забывает закрыть) дескриптор процесса каждый раз, когда я открываю видео в Windows Explorer.

Visual Studio забывает закрыть дескрипторы как минимум двух процессов, в одном случае это воспроизводится всегда. Просто запустите сборку проекта и подождите

15 минут пока процесс MSBuild.exe закроется. Можно также выставить опцию “set MSBUILDDISABLENODEREUSE=1” и тогда MSBuild.exe закроется сразу по окончанию сборки и потерянный дескриптор будет виден сразу. К сожалению, какой-то негодяй в Microsoft исправил эту проблему и фикс должен выйти в обновлении VS 15.6, так что поторопитесь воспроизвести её, пока это ещё работает (надеюсь, не нужно объяснять, что это была шутка и никакой он на самом деле не негодяй).

Также вы можете использовать для просмотра забытых процессов программу Process Explorer, сконфигурировав её нижнюю панель так, как это показано ниже (заметьте, что в этом случае будут показаны забытые дескрипторы как для процессов, так и для потоков):

Вот пару примеров найденных багов (о некоторых сообщено разработчикам, но не о всех):

Утечка в CcmExec.exe (описанный выше случай с 500 000 зомби) — разработчики работают над исправлением
Утечка в Program Compatibility Assistant Service — проблема исследуется
Утечка в devenv.exe + MSBuild.exe (проблема уже исправлена)
Утечка в devenv.exe + ServiceHub.Host.Node.x86.exe (багрепорт отправлен)
Утечка в IntelCpHeciSvc.exe + Video.UI.exe для каждого открытого видеофайла (Intel приняла багрепорт и переслала его в Lenovo)
Утечка в RuntimeBroker.exe + MicrosoftEdge и Video.UI.exe (возможно, имеет отношение к некоторым другим багам в RuntimeBroker.exe)
Утечка в AudioSrv + Video.UI.exe
Утечка в одном внутреннем инструменте Google из-за использования старой версии psutil
Утечка в утилитах от Lenovo: tphkload.exe теряет один дескриптор, SUService.exe теряет три
Утечка в Synaptic’s SynTPEnh.exe

Используя Process Explorer, я заметил, что NVDisplay.Container.exe открывает

5000 дескрипторов на событие \BaseNamedObjects\NvXDSyncStop-61F8EBFF-D414-46A7-90AE-98DD58E4BC99, создавая новый дескриптор каждые две минуты. Я так понимаю, они хотят быть супер-уверены в том, что могут остановить NvXDSync? Багрепорт Nvidia отправлен.

Corsair Link Service создаёт

15 дескрипторов в секунду, не освобождает их совсем. Багрепорт отправлен.

Adobe’s Creative Cloud теряет тысячи дескрипторов (около 6500 в день, по моим подсчётам). Багрепорт отправлен.

Удивительно, что никто до этого особо не обращал внимание на подобные баги. Эй, Microsoft, возможно, стоит собирать статистику по таким случаям и что-то предпринимать по этому поводу? Эй, Intel и Nvidia, почистите немного ваш код. Помните, я наблюдаю за вами.

А теперь вы можете взять утилиту FindZombieHandles, запустить её на вашей машине и рассказать о своих находках. Также вы можете использовать в экспериментах диспетчер задач и Process Explorer.

Ищем и убиваем zombie процессы

Что же это такое?
Это дочерний процесс в Unix-системе, завершивший своё выполнение, но ещё присутствующий в списке процессов операционной системы, чтобы дать родительскому процессу считать код завершения. Процесс при завершении освобождает все свои ресурсы (за исключением PID — идентификатора процесса) и становится «зомби» — пустой записью в таблице процессов, хранящей код завершения для родительского процесса.
Система уведомляет родительский процесс о завершении дочернего с помощью сигнала SIGCHLD. Предполагается, что после получения SIGCHLD он считает код возврата с помощью системного вызова wait(), после чего запись зомби будет удалена из списка процессов. Если родительский процесс игнорирует SIGCHLD (а он игнорируется по умолчанию), то зомби остаются до его завершения.

А теперь возникают вопросы: как же всё-таки их найти и убить? Найти их очень просто. Вот несколько вариантов:

1)
top | grep zombie
225 processes: 1 running, 222 sleeping, 2 zombie

2)
ps aux | grep -w Z
root 3994 0,0 0,0 0 0 ?? Z 13июн11 16:23,02 <defunct>
root 3995 0,0 0,0 0 0 ?? Z 13июн11 13:43,28 <defunct>

3)
ps -alx | awk ‘$10

Что касается “убийства”, то их нельзя просто так убить. Самый правильный вариант – найти родительский процесс и перезапустить его. Некоторые могут посоветовать и перегрузиться, но это не выход.

Находим родительский процесс:

ps ajx | grep -w Z
root 3994 3992 3992 3992 0 Z ?? 16:23,02 <defunct>
root 3995 3992 3992 3992 0 Z ?? 13:43,28 <defunct>

3-я колонка как раз и показывает pid родительского процесса. Смотрим, что это за процесс:

ps auxww | grep 3992
root 3992 0,0 0,2 30664 9872 ?? Ss 13июн11 0:08,21 [exilog_agent] (perl5.12.3)

Собственно мы нашли виновника. Это exilog_agent. А дальше – либо просто прибиваем родительский процесс либо перезапускаем его: