Существует ли верхний предел для числа процессов зомби, которые вы можете иметь?

Я имел обыкновение работать с системой HP-UX, и старый администратор сказал мне, что есть верхний предел на число процессов зомби, которые вы можете иметь в системе, я думаю, 1024.

• Это жесткий потолок факта? Я думаю, что вы можете иметь любое количество зомби, как если бы вы могли иметь любое количество процессов ...?
• Это разная ценность от дистрибутива к дистрибутиву?
• Что произойдет, если мы достигнем верхнего предела и попытаемся создать еще одного зомби?

У меня нет HP-UX, и я никогда не был большим поклонником HP-UX.

Похоже, что в Linux существует ограничение на количество дочерних процессов для каждого процесса или, возможно, для каждого пользователя. Вы можете увидеть это с помощью limitвстроенного Zsh (похоже, ulimit -uв bash):

1002 % limit
cputime         unlimited
filesize        unlimited
datasize        unlimited
stacksize       8MB
coredumpsize    0kB
memoryuse       unlimited
maxproc         16136
  ...

Это на ноутбуке Arch Linux.

Я написал небольшую программу для проверки этого ограничения:

#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/wait.h>

volatile int sigchld_cnt = 0;

voida
sigchld_hdlr(int signo)
{
        ++sigchld_cnt;
}

int
main(int ac, char **av)
{
        int looping = 1;
        int child_cnt = 0;
        int status;

        signal(SIGCHLD, sigchld_hdlr);

        printf("Parent PID %d\n", getpid());

        while (looping)
        {
                switch (fork())
                {
                case 0:
                        _exit(0);
                        break;
                case -1:
                        fprintf(stderr, "Problem with fork(), %d children: %s\n",
                                child_cnt, strerror(errno));
                        looping = 0;
                        break;
                default:
                        ++child_cnt;
                        break;
                }
        }

        fprintf(stderr, "Sleeping, forked %d child processes\n", child_cnt);
        fprintf(stderr, "Received %d sigchild\n", sigchld_cnt);
        sleep(10);

        looping = 1;
        do {
                int x = wait(&status);

                if (x != -1)
                        --child_cnt;
                else if (errno != EINTR) {
                        fprintf(stderr, "wait() problem %d children left: \%s\n",
                                child_cnt, strerror(errno));
                        looping = 0;
                }
        } while (looping);

        printf("%d children left, %d SIGCHLD\n", child_cnt, sigchld_cnt);

        return 0;
}

Было удивительно трудно «собрать» всех зомби, позвонив wait(2)достаточно раз. Кроме того, количество полученных сигналов SIGCHLD никогда не совпадает с числом разветвленных дочерних процессов: я полагаю, что ядро ​​linux иногда отправляет 1 SIGCHLD для ряда завершенных дочерних процессов.

В любом случае, на моем ноутбуке Arch Linux я получил 16088 дочерних процессов, и это должно быть количество зомби, так как программа не выполняет wait(2)системные вызовы в обработчике сигналов.

На моем сервере Slackware 12 я получаю 6076 дочерних процессов, что близко соответствует значению maxproc 6079. У моего ID пользователя есть еще 2 запущенных процесса sshdи Zsh. Наряду с первым, не зомби-экземпляром программы выше, это 6079.

fork(2)Системный вызов не с «Ресурс временно недоступна» ошибка. Я не вижу никаких других доказательств того, что ресурс недоступен. Я получаю несколько разные числа, если я запускаю свою программу одновременно в 2 разных xterms, но они складываются в одно и то же число, как если бы я запускал ее в одном xterm. Я предполагаю, что это записи таблицы процессов, или подкачка, или какой-то общесистемный ресурс, а не просто произвольный предел.

У меня больше ничего нет, чтобы попробовать это прямо сейчас.

Я не знаю, каковы пределы HP-UX. Однако я могу сказать вам, что логическая реализация состоит в том, чтобы иметь таблицу процессов с максимальным размером. Общее количество записей в таблице процессов теоретически ограничено диапазоном идентификаторов процессов, но большинство реализаций имеют ограничение на размер таблицы, которое дает гораздо меньший максимум. Большинство вариантов Unix также имеют ограничение на количество пользователей; Вы можете увидеть предел, запустив ulimit -uв bash.

Я не ожидаю, что система Unix будет иметь отдельный лимит на зомби, а не на количество идентификаторов процессов (которое включает в себя как реальные процессы, так и зомби). Поэтому, когда процесс умирает и становится зомби, это не влияет на предел: ресурс (запись в таблице процессов) выделяется, когда процесс разветвляется, и освобождается, когда процесс пожинается.

Я думаю, что вы можете иметь любое количество зомби, как если бы вы могли иметь любое количество процессов ...?

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

Это разная ценность от дистрибутива к дистрибутиву?

Конечно, как и многие другие параметры. Вы не должны ретранслировать на определенный размер, или если он достаточно большой, чтобы провести много зомби процесса. Если вы получаете слишком много зомби, решение не является большим столом, потому что оно будет в конечном итоге заполнено. Процесс зомби сам по себе неплох, но слишком большое количество накопленных процессов зомби является признаком «плохо себя ведущей» программы, которая допускает такие процессы зомби.

Что произойдет, если мы достигнем верхнего предела и попытаемся создать еще одного зомби?

Как только таблица процессов заполнена обычными и зомби-процессами, новый регулярный процесс не может быть создан, даже если в системе достаточно ресурсов памяти, процессора и т. Д. Единственный недостающий ресурс - это просто одна запись в таблице процессов. Уже запущенные программы - даже те, которые "хорошо себя ведут" - начнут давать сбой, когда им потребуется создать подпроцесс. Новые программы не могут быть запущены, и даже запуск отдельных команд завершится ошибкой.