Existe um limite superior para o número de processos zumbis que você pode ter?

Eu costumava trabalhar com um sistema HP-UX e o antigo administrador me disse que há um limite superior no número de processos zumbis que você pode ter no sistema, acredito que 1024.

• Esse é um teto difícil? Eu acho que você poderia ter qualquer número de zumbis, como se você pudesse ter qualquer número de processos ...?
• É um valor diferente de distribuição para distribuição?
• O que ocorre se atingirmos o limite superior e tentarmos criar outro zumbi?

Não tenho o HP-UX disponível para mim e nunca fui um grande fã do HP-UX.

Parece que no Linux, existe um limite por processo ou talvez por usuário de quantos processos filhos existem. Você pode vê-lo com o limitZsh embutido (parece análogo ao ulimit -ubash):

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

Está em um laptop Arch linux.

Eu escrevi um pequeno programa para testar esse 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;
}

Foi surpreendentemente difícil "coletar" todos os zumbis chamando wait(2)vezes suficientes. Além disso, o número de sinais SIGCHLD recebidos nunca é o mesmo que o número de processos filhos bifurcados: acredito que o kernel do linux às vezes envia 1 SIGCHLD para vários processos filhos encerrados.

De qualquer forma, no meu laptop Arch linux, tenho 16088 processos filhos bifurcados, e esse deve ser o número de zumbis, pois o programa não faz wait(2)chamadas do sistema no manipulador de sinais.

No meu servidor Slackware 12, recebo 6076 processos filhos, o que corresponde ao valor de maxproc 6079. Meu ID do usuário possui 2 outros processos em execução sshde o Zsh. Juntamente com a primeira instância não zumbi do programa acima, que produz 6079.

A fork(2)chamada do sistema falha com o erro "Recurso temporariamente indisponível". Não vejo nenhuma outra evidência de qual recurso está indisponível. Eu recebo números um pouco diferentes se eu executar meu programa simultaneamente em 2 xterms diferentes, mas eles somam o mesmo número como se eu o executasse em um xterm. Presumo que sejam entradas da tabela de processos, ou swap ou algum recurso de todo o sistema, e não apenas um limite arbitrário.

Não tenho mais nada em execução para experimentá-lo agora.

Não sei quais são os limites do HP-UX. No entanto, posso dizer que a implementação lógica é ter uma tabela de processos com um tamanho máximo. O número total de entradas da tabela de processos é teoricamente limitado pelo intervalo de IDs do processo, mas a maioria das implementações possui um limite de tamanho para a tabela, que gera um máximo muito menor. A maioria das variantes unix também tem um limite por usuário do número de processos; você pode ver o limite executando ulimit -uno bash.

Não espero que um sistema unix tenha um limite separado para zumbis, em vez do número de IDs de processo (que inclui processos reais e zumbis). Portanto, quando um processo morre e se torna um zumbi, isso não afeta o limite: o recurso (a entrada na tabela de processos) é alocado quando um processo se bifurca e liberado quando o processo é colhido.

Eu acho que você poderia ter qualquer número de zumbis, como se você pudesse ter qualquer número de processos ...?

Um processo zumbi é finalmente um processo - em um estado especial - e os processos zumbis são limitados à disponibilidade e tamanho da tabela de processos, como nos processos regulares .

É um valor diferente de distribuição para distribuição?

Certamente, como muitos outros parâmetros. Você não deve retransmitir um tamanho específico, ou se for grande o suficiente para suportar muitos processos zumbis. Se você está recebendo muitos zumbis, a solução não é uma mesa grande, porque ela ficará cheia. Um processo de zumbi não é ruim por si só, mas ter muitos processos de zumbis acumulados é uma indicação de um programa "mal comportado" que permite que esses processos sejam zumbis.

O que ocorre se atingirmos o limite superior e tentarmos criar outro zumbi?

Depois que a tabela de processos estiver cheia - de processos regulares e zumbis -, nenhum novo processo regular poderá ser criado, mesmo que o sistema tenha recursos suficientes - memória, processador etc. -. O único recurso que falta é apenas uma entrada na tabela de processos. Os programas em execução, mesmo os "bem comportados", começarão a falhar quando exigirem a criação de um subprocesso. Novos programas não podiam ser iniciados e até a execução de comandos únicos falharia.