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?
Best Answer
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 toulimit -u
in bash):That's on an Arch linux laptop.
I wrote a little program to test that limit:
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.