C'è un limite massimo al numero di processi di zombi che puoi avere?

Lavoravo con un sistema HP-UX e il vecchio amministratore mi ha detto che esiste un limite massimo al numero di processi zombi che puoi avere sul sistema, credo 1024.

• Si tratta di un limite massimo? Penso che potresti avere un numero qualsiasi di zombi proprio come se tu potessi avere un numero qualsiasi di processi ...?
• È diverso dal valore alla distribuzione?
• Cosa succede se raggiungiamo il limite superiore e proviamo a creare un altro zombi?

Non ho HP-UX disponibile per me e non sono mai stato un grande fan di HP-UX.

Sembra che su Linux, un limite per processo o forse per utente su quanti processi figlio esistano. Puoi vederlo con limitZsh integrato (sembra essere analogo a ulimit -uin bash):

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

È su un laptop Arch Linux.

Ho scritto un piccolo programma per testare quel limite:

#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;
}

È stato sorprendentemente difficile "collezionare" tutti gli zombi chiamando wait(2)abbastanza volte. Inoltre, il numero di segnali SIGCHLD ricevuti non è mai uguale al numero di processi figlio biforcati: credo che il kernel Linux a volte mandi 1 SIGCHLD per un numero di processi figlio usciti.

Ad ogni modo, sul mio laptop Arch Linux, ottengo 16088 processi secondari biforcati, e questo deve essere il numero di zombi, poiché il programma non esegue wait(2)chiamate di sistema nel gestore del segnale.

Sul mio server Slackware 12, ottengo 6076 processi figlio, che corrispondono strettamente al valore di maxproc 6079. Il mio ID utente ha altri 2 processi in esecuzione sshde Zsh. Insieme alla prima istanza non zombi del programma sopra che fa 6079.

La fork(2)chiamata di sistema ha esito negativo con un errore "Risorsa temporaneamente non disponibile". Non vedo altre prove di quale risorsa non sia disponibile. Ottengo numeri leggermente diversi se eseguo il mio programma contemporaneamente in 2 xterm diversi, ma si sommano allo stesso numero come se lo avessi eseguito in un xterm. Presumo che sia voci della tabella dei processi, o swap o qualche risorsa a livello di sistema, e non solo un limite arbitrario.

Non ho nient'altro in esecuzione per provarlo adesso.

Non so quali siano i limiti di HP-UX. Posso dirti tuttavia che l'implementazione logica deve avere una tabella di processo con una dimensione massima. Il numero totale di voci della tabella di processo è teoricamente limitato dalla gamma di ID di processo, ma la maggior parte delle implementazioni ha un limite di dimensione per la tabella che produce un massimo molto più piccolo. La maggior parte delle varianti unix ha anche un limite per utente sul numero di processi; puoi vedere il limite eseguendo ulimit -uin bash.

Non mi aspetto che un sistema unix abbia un limite separato per gli zombi, piuttosto che per il numero di ID di processo (che include sia i processi effettivi che gli zombi). Quindi, quando un processo muore e diventa uno zombi, ciò non influisce sul limite: la risorsa (la voce nella tabella dei processi) viene allocata quando un processo si biforca e viene liberata quando il processo viene raccolto.

Penso che potresti avere un numero qualsiasi di zombi proprio come se tu potessi avere un numero qualsiasi di processi ...?

Un processo zombi è finalmente un processo, in uno stato speciale, quindi i processi zombi sono limitati alla disponibilità e alle dimensioni della tabella dei processi, come per i processi regolari .

È diverso dal valore alla distribuzione?

Sicuramente, come molti altri parametri. Non dovresti fare affidamento su una dimensione specifica o se è abbastanza grande da contenere molti processi di zombi. Se stai ricevendo troppi zombi, la soluzione non è un grande tavolo, perché alla fine diventerà piena. Un processo di zombi non è male da solo, ma avere troppi processi di zombi accumulati è un'indicazione di un programma "mal comportato" che sta permettendo tali processi di zombi.

Cosa succede se raggiungiamo il limite superiore e proviamo a creare un altro zombi?

Una volta che la tabella dei processi è piena di processi regolari e zombi, non è possibile creare alcun nuovo processo regolare, anche se il sistema dispone di risorse sufficienti: memoria, processore, ecc. L'unica risorsa mancante è solo una singola voce nella tabella dei processi. I programmi già in esecuzione, anche quelli "ben educati", inizieranno a fallire quando richiedono la creazione di un processo secondario. Non è stato possibile avviare nuovi programmi e anche l'esecuzione di singoli comandi fallirebbe.