1

I'm developing a program (Grand parent process) that automatically relaunch a process (parent process) that calls two other processes (children processes) in case of errors.

If one of the children processes misbehave, the parent process try to close the application gracefully and the grand parent process restart everything. However, in case of bug or unexpected behavior, the grand parent process :

  1. kills the parent process (which kills all the children)
  2. Restart the parent process

Due to probably a problem in my code, the parents processes survive as zombies and sometime I find my embedded linux with 12 or 20 zombies. I know that zombies use very little ressources (if I'm not mistaken : only their entry into the process table).

My question, is there a theoretical limit to zombies number ?

bad_coder
  • 11,289
  • 20
  • 44
  • 72
JDoe
  • 15
  • 5

2 Answers2

2

My question, is there a theoretical limit to zombies number ?

Yes. It is whatever the maximum size of the kernel's process table is. This will vary from kernel to kernel and according to adjustable kernel parameters, but it is likely to be at least in the thousands.

But as long as we're here, let's address a couple of other things:

the grand parent process [...] kills the parent process (which kills all the children)

Killing a process does not automatically kill its children. They will be inherited by process ID 1, which you can observe in the process list if the processes live long enough. Cleaning those up after they terminate is one of the responsibilities of process 1, which may be why you have the impression that you are killing the grandchildren -- you probably don't see them left behind as zombies.

If you want to forcibly kill the children along with their parent, then you should be able to do so by putting the parent process in its own process group, and killing the whole group. (You need a separate process group so that the grandparent does not kill itself.)

Due to probably a problem in my code, the parents processes survive as zombies

This happens when a process's parent continues to run but does not wait(), waitpid(), or waitid() for the process after it terminates. In fact, that's closely related to zombie processes: they are indeed very light, because all they carry is the data that could be reported via one of those functions. Thus, "survive" is not a particularly apt description: a zombie process is no longer running; all that remains is some data about how it terminated.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
1

I believe the only negative effect of keeping Zombie processes around is that they take up space in the kernel process table. The max number of zombies you can keep around should be the max number of processes your kernel supports, which you can query with cat /proc/sys/kernel/pid_max

Paul
  • 88
  • 9