Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

I used to work with an HP-UX system and the old admin told me there is an upper limit on the number of zombie processes you can have on the system, I believe 1024.

  • Is this a hard fact ceiling? I think you could have any number of zombies just as if you can have any number of processes...?
  • Is it different value from distro to distro?
  • What occurs if we hit the upper limit and try to create another zombie?
share|improve this question
According to this blog article the only limit on Linux is the number of PIDs, which only incidentally affects zombies. –  bahamat Jul 28 '12 at 0:18
Both answers below mention ulimit -u. I was confused for a while as man ulimit got me a C routine with no mention of -u. The mentioned ulimit is in fact a built-in bash tool and it is described in the bash manpage. –  Emanuel Berg Jul 30 '12 at 16:43

3 Answers 3

up vote 8 down vote accepted

I don't have HP-UX available to me, and I've never been a big HP-UX fan.

It appears that on Linux, a per-process or maybe per-user limit on how many child processes exists. You can see it with the limit Zsh built-in (seems to be analogous to ulimit -u in bash):

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

That's on an Arch linux laptop.

I wrote a little program to test that limit:

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

sigchld_hdlr(int signo)

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:
                case -1:
                        fprintf(stderr, "Problem with fork(), %d children: %s\n",
                                child_cnt, strerror(errno));
                        looping = 0;

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

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

                if (x != -1)
                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;

It was surprisingly difficult to "collect" all the zombies by calling wait(2) enough times. Also, the number of SIGCHLD signals received is never the same as the number of child processes forked: I believe the linux kernel sometimes sends 1 SIGCHLD for a number of exited child processes.

Anyway, on my Arch linux laptop, I get 16088 child processes forked, and that has to be the number of zombies, as the program doesn't do wait(2) system calls in the signal handler.

On my Slackware 12 server, I get 6076 child processes, which closely matches the value of maxproc 6079. My user ID has 2 other processes running, sshd and Zsh. Along with the first, non-zombie instance of the program above that makes 6079.

The fork(2) system call fails with a "Resource temporarily unavailable" error. I don't see any other evidence of what resource is unavailable. I do get somewhat different numbers if I run my program simultaneously in 2 different xterms, but they add up to the same number as if I run it in one xterm. I assume it's process table entries, or swap or some system-wide resource, and not just an arbitrary limit.

I don't have anything else running to try it on right now.

share|improve this answer

I don't know what HP-UX's limits are. I can tell you however that the logical implementation is to have a process table with a maximum size. The total number of process table entries is theoretically limited by the range of process IDs, but most implementations have a size limit for the table which yields a much smaller maximum. Most unix variants have a per-user limit on the number of processes, too; you can see the limit by running ulimit -u in bash.

I don't expect a unix system to have a separate limit on zombies, rather than on the number of process IDs (which includes actual processes as well as zombies). So when a process dies and becomes a zombie, that doesn't affect the limit: the resource (the entry in the process table) is allocated when a process forks and freed when the process is reaped.

share|improve this answer

I think you could have any number of zombies just as if you can have any number of processes...?

A zombie process is finally a process -in a special state- then zombie processes are limited to availability and size of the process table, as for regular processes.

Is it different value from distro to distro?

Surely, as many other parameters. You should not relay on a specific size, or if it is big enough to hold many zombie process. If you are getting too many zombies the solution is not a big table, because it will became eventually full. A zombie process is not bad by itself, but having too many accumulated zombie processes is an indication of a "badly behaved" program that is allowing such that zombie processes.

What occurs if we hit the upper limit and try to create another zombie?

Once the process table is full -of regular and zombie processes-, no new -regular- process can be created, even if the system has enough resources -memory, processor, etc.-. The only lacking resource is just a single entry in the process table. Already running programs -even those "well behaved"- will start to fail when they require to create a sub-process. New programs could not be started, and even running single commands would fail.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.