Процессы-зомби в Unix-подобных системах

Введение

Процесс, который не выполняется, но присутствует в таблице процессов.

В операционных системах Unix и Unix-подобных, зомби-процесс или неактивный процесс – это процесс, который завершил выполнение (через системный вызов exit), но все еще имеет запись в таблице процессов: это процесс в "завершённом состоянии". Это происходит с дочерними процессами, где запись все еще необходима, чтобы родительский процесс мог прочитать статус выхода своего дочернего процесса: как только статус выхода прочитан с помощью системного вызова wait, запись зомби удаляется из таблицы процессов, и процесс считается "пожинаемым". Дочерний процесс сначала становится зомби, и только затем удаляется из таблицы ресурсов. При нормальной работе системы зомби немедленно ожидаются родительским процессом и затем пожинаются системой. Процессы, которые остаются зомби в течение длительного времени, обычно указывают на ошибку и могут приводить к утечке ресурсов. Как правило, единственный ресурс ядра, который они занимают, – это запись в таблице процессов, их идентификатор процесса. Однако зомби могут также удерживать открытые буферы, потребляя память. Зомби могут удерживать дескрипторы файлов, что препятствует выделению пространства для этих файлов файловой системе. Этот эффект можно увидеть по разнице между командами du и df. В то время как du может показывать большое количество свободного дискового пространства, df покажет заполненный раздел. Если зомби не будут удалены, это может заполнить корневой раздел и привести к сбою системы. Термин "зомби-процесс" происходит от общепринятого определения зомби – неживого человека. В метафоре этого термина дочерний процесс "умер", но еще не был "пожинаем". В отличие от обычных процессов, команда kill не оказывает никакого эффекта на зомби-процесс. Зомби-процессы не следует путать с процессами-сиротами, процессами, которые все еще выполняются, но родительский процесс которых завершился. Когда родительский процесс завершается, сиротский дочерний процесс переходит под управление init. Когда процесс-сирота завершается, он не остается зомби-процессом, а ожидается init.

Обзор

Когда процесс завершается выходом, вся память и ресурсы, связанные с ним, освобождаются для использования другими процессами. Однако запись процесса в таблице процессов сохраняется. Родительский процесс может прочитать статус выхода дочернего процесса, выполнив системный вызов `wait`, после чего зомби-процесс удаляется. Вызов `wait` может быть выполнен в последовательном коде, но чаще всего он выполняется в обработчике сигнала `SIGCHLD`, который родительский процесс получает каждый раз, когда завершается дочерний процесс. После удаления зомби его идентификатор процесса (PID) и запись в таблице процессов могут быть повторно использованы. Однако, если родительский процесс не выполнит вызов `wait`, зомби-процесс останется в таблице процессов, что приведет к утечке ресурсов. В некоторых ситуациях это может быть намеренно – родительский процесс хочет продолжать удерживать этот ресурс, например, если он создает другой дочерний процесс, чтобы гарантировать, что ему не будет выделен тот же PID. На современных UNIX-подобных системах (соответствующих спецификации SUSv3 в этом отношении) применяется следующий особый случай: если родительский процесс явно игнорирует сигнал `SIGCHLD`, установив его обработчик в `SIG_IGN` (а не просто игнорируя сигнал по умолчанию) или установив флаг `SA_NOCLDWAIT`, вся информация о статусе выхода дочернего процесса будет отброшена, и зомби-процессы не останутся. Зомби-процессы можно идентифицировать в выводе команды `ps` Unix по наличию символа "Z" в столбце "STAT". Зомби-процессы, существующие в течение длительного времени, обычно указывают на ошибку в родительской программе или на необычное решение не "собирать" дочерние процессы (см. пример). Если родительский процесс больше не работает, зомби-процессы обычно указывают на ошибку в операционной системе. Как и в случае с другими утечками ресурсов, наличие нескольких зомби-процессов само по себе не является критичным, но может указывать на проблему, которая станет серьезной при увеличении нагрузки. Поскольку зомби-процессам не выделяется память (используется только память для записи в таблице процессов), основная проблема при большом количестве зомби-процессов заключается не в нехватке памяти, а в исчерпании записей в таблице процессов, а именно – идентификаторов процессов. Однако зомби-процессы могут удерживать открытыми буферы, связанные с файловыми дескрипторами, тем самым потребляя память. Зомби-процессы также могут удерживать файловый дескриптор удаленного файла, что препятствует восстановлению i-узлов файловой системой. Следовательно, команда для отображения использования диска не будет учитывать удаленные файлы, пространство которых не может быть повторно использовано из-за удерживаемого зомби-процессом файлового дескриптора. Чтобы удалить зомби-процессы из системы, сигнал `SIGCHLD` можно отправить родительскому процессу вручную с помощью команды `kill`. Если родительский процесс по-прежнему отказывается "собирать" зомби-процесс, и если допустимо завершить родительский процесс, следующим шагом может быть его удаление. Когда процесс теряет родительский процесс, `init` становится его новым родителем. `init` периодически выполняет системный вызов `wait` для "сбора" любых зомби-процессов, у которых `init` является родителем.

When a process ends via exit, all of the memory and resources associated with it are deallocated so they can be used by other processes. However, the process's entry in the process table remains. The parent can read the child's exit status by executing the wait system call, whereupon the zombie is removed. The wait call may be executed in sequential code, but it is commonly executed in a handler for the SIGCHLD signal, which the parent receives whenever a child has died. After the zombie is removed, its process identifier (PID) and entry in the process table can then be reused. However, if a parent fails to call wait, the zombie will be left in the process table, causing a resource leak. In some situations this may be desirable – the parent process wishes to continue holding this resource – for example if the parent creates another child process it ensures that it will not be allocated the same PID. On modern UNIX like systems (that comply with SUSv3 specification in this respect), the following special case applies: if the parent explicitly ignores SIGCHLD by setting its handler to SIG IGN (rather than simply ignoring the signal by default) or has the SA NOCLDWAIT flag set, all child exit status information will be discarded and no zombie processes will be left. Zombies can be identified in the output from the Unix ps command by the presence of a "Z" in the "STAT" column. Zombies that exist for more than a short period of time typically indicate a bug in the parent program, or just an uncommon decision to not reap children (see example). If the parent program is no longer running, zombie processes typically indicate a bug in the operating system. As with other resource leaks, the presence of a few zombies is not worrisome in itself, but may indicate a problem that would grow serious under heavier loads. Since there is no memory allocated to zombie processes – the only system memory usage is for the process table entry itself – the primary concern with many zombies is not running out of memory, but rather running out of process table entries, concretely process ID numbers. However, zombies can hold open buffers that are associated with file descriptors, and thereby cause memory to be consumed by the zombie. Zombies can also hold a file descriptor to a file that has been deleted. This prevents the file system from recovering the i nodes for the deleted file. Therefore, the command to show disk usage will not count the deleted files whose space cannot be reused due to the zombie holding the filedescriptor. To remove zombies from a system, the SIGCHLD signal can be sent to the parent manually, using the kill command. If the parent process still refuses to reap the zombie, and if it would be fine to terminate the parent process, the next step can be to remove the parent process. When a process loses its parent, init becomes its new parent. init periodically executes the wait system call to reap any zombies with init as parent.

Пояснение

В первом цикле исходный (родительский) процесс порождает 10 копий самого себя. Каждый из этих дочерних процессов (определяемый тем, что `fork` возвращает ноль) выводит сообщение, засыпает и завершается. Все дети создаются практически одновременно (поскольку родительский процесс выполняет очень мало действий в цикле), поэтому время, когда каждый из них получит процессорное время впервые, несколько случайно, что и приводит к перемешанному порядку их сообщений. В течение цикла создается массив идентификаторов дочерних процессов. Копия массива `pids[]` присутствует во всех 11 процессах, но полная она только в родительском процессе – в копии каждого дочернего процесса будут отсутствовать идентификаторы дочерних процессов с меньшими номерами, а вместо собственного идентификатора будет ноль. (Впрочем, это не имеет большого значения, поскольку этот массив фактически использует только родительский процесс.) Второй цикл выполняется только в родительском процессе (поскольку все дочерние процессы уже завершили работу к этому моменту) и ожидает завершения каждого дочернего процесса. Он ожидает завершения дочернего процесса, который засыпал на 10 секунд; все остальные уже давно завершились, поэтому все сообщения (кроме первого) появляются быстро друг за другом. Здесь нет возможности случайного порядка, поскольку всем управляет цикл в одном процессе. Первое сообщение от родительского процесса фактически появилось раньше любых сообщений от дочерних процессов – родительский процесс смог перейти ко второму циклу до того, как какой-либо из дочерних процессов начал выполняться. Это опять же просто случайное поведение планировщика процессов – сообщение "parent9" могло появиться в любом месте последовательности до "parent8". Дочерние процессы с 0 по 8 проводят одну или несколько секунд в состоянии между завершением работы и моментом, когда родительский процесс вызывает `waitpid` для них. Родительский процесс уже ожидал завершения дочернего процесса 9 до того, как тот завершился, поэтому этот процесс практически не находился в состоянии зомби.