Чи існує верхня межа кількості зомбі-процесів?

Раніше я працював із системою HP-UX, і старий адміністратор сказав мені, що в системі існує верхня межа кількості процесів зомбі, я вважаю, 1024.

• Це важка стеля фактів? Я думаю, що ти можеш мати будь-яку кількість зомбі так, як ніби ти можеш мати будь-яку кількість процесів ...?
• Чи відрізняється воно від distro to distro?
• Що відбувається, якщо ми потрапили на верхню межу і спробуємо створити ще одного зомбі?

У мене немає HP-UX для мене, і я ніколи не був великим шанувальником HP-UX.

Виявляється, що в Linux обмеження на кількість процесів або, можливо, на кожного користувача, існує. Ви можете бачити це за допомогою limitвбудованого Zsh (здається, аналогічно ulimit -ubash):

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і ЗШ. Поряд із першим екземпляром програми, що не є зомбі, вище 6079.

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

У мене нічого більше не працює, щоб спробувати це зараз.

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

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

Я думаю, що ти можеш мати будь-яку кількість зомбі так, як ніби ти можеш мати будь-яку кількість процесів ...?

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

Чи відрізняється воно від distro to distro?

Звичайно, як і багато інших параметрів. Ви не повинні ретранслюватися на певний розмір, або якщо він досить великий, щоб утримати багато процесів зомбі. Якщо ви отримуєте занадто багато зомбі, рішення не є великим столом, оскільки воно з часом стане повноцінним. Процес зомбі сам по собі не поганий, але занадто багато накопичених зомбі-процесів є ознакою програми "погано поводиться", яка дозволяє такі, що зомбі процеси.

Що відбувається, якщо ми потрапили на верхню межу і спробуємо створити ще одного зомбі?

Після того, як таблиця процесів буде заповнена звичайними та зомбі-процесами, жоден новий -регулярний процес не може бути створений, навіть якщо система має достатньо ресурсів - пам'ять, процесор тощо. Єдиний недолік ресурсу - це лише один запис у таблиці процесів. Уже запущені програми - навіть у тих, хто «добре себе поводив» - почнуть виходити з ладу, коли їм потрібно буде створити підпроцес. Не вдалося запустити нові програми, і навіть виконання окремих команд не вдасться.