Unreapable zombie

This is a discussion on Unreapable zombie within the Linux Programming forums, part of the Platform Specific Boards category; This is just a rant, not a question. Suppose you have process A, which forks child B. Suppose process B ...

  1. #1
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,263

    Unreapable zombie

    This is just a rant, not a question.

    Suppose you have process A, which forks child B. Suppose process B exits, becoming a zombie. Then, process A exits without reaping child B. Child B is now re-parented to init, but since it is already a zombie, init never receives a SIGCHLD and thus does not reap the zombie.

    Result? A zombie that you can't get rid of. I hate it.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  2. #2
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,263
    Hmm. Well it appears that overnight, init finally decided to reap my zombie. It sure took it a damn long while though. Sounds like a good method for DoS'ing a system -- fork() off a child which sleep()'s for a little while then exits, but before it exits, quit yourself. Eventually the process table would get filled up with zombies, disabling the whole damn system.

    Ugh.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  3. #3
    int x = *((int *) NULL); Cactus_Hugger's Avatar
    Join Date
    Jul 2003
    Location
    Banks of the River Styx
    Posts
    902
    This is not supposed to happen.
    Quote Originally Posted by man wait
    A child that terminates, but has not been waited for becomes a "zombie". The kernel maintains a minimal set of information about the zombie process (PID, termination status, resource usage information) in order to allow the parent to later perform a wait to obtain information about the child. As long as a zombie is not removed from the system via a wait, it will consume a slot in the kernel process table, and if this table fills, it will not be possible to create further processes. If a parent process terminates, then its "zombie" children (if any) are adopted by init(8), which automatically performs a wait to remove the zombies.
    Now, you can fill the PID table by just fork()-ing repeatedly, and not returned, known as "Fork bombing"
    long time; /* know C? */
    Unprecedented performance: Nothing ever ran this slow before.
    Any sufficiently advanced bug is indistinguishable from a feature.
    Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
    The best way to accelerate an IBM is at 9.8 m/s/s.
    recursion (re - cur' - zhun) n. 1. (see recursion)

  4. #4
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,263
    Quote Originally Posted by Cactus_Hugger View Post
    This is not supposed to happen.


    Now, you can fill the PID table by just fork()-ing repeatedly, and not returned, known as "Fork bombing"
    Yes -- the thing I don't like is how long it takes for init to reap. It does eventually get around to it, but it seems to be on a timer at least several hours long. So if you do this fast enough, init won't keep up with it.

    I'm familiar with fork bombing, but zombie bombing is worse, because you can't kill the zombies. If init doesn't reap them for hours, you're screwed for hours.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  5. #5
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Hmmm. I've noticed this happen before and I always dump the software which caused it. Interesting.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  6. #6
    int x = *((int *) NULL); Cactus_Hugger's Avatar
    Join Date
    Jul 2003
    Location
    Banks of the River Styx
    Posts
    902
    Code:
    ./zombie;ps -ef | grep zombie
    Always turns up nothing or the grep process. By the time ps can enumerate the processes, init has reaped the zombie. (./zombie pauses before exiting, so you can verify the zombie.)
    Code:
    #include <stdio.h>
    #include <unistd.h>
    
    int main()
    {
    	int ret;
    
    	ret = fork();
    	if(ret < 0)
    	{
    		perror("zombie");
    		return 1;
    	}
    	else if(ret == 0)
    	{
    		// Child
    		return 0;
    	}
    	else
    	{
    		printf("Child forked. (PID = %d)\nType a number followed by enter to quit.\n", ret);
    		scanf("%d", &ret);
    		return 0;
    	}
    	return 0;
    }
    My init seems to clean them up fairly quickly. According to Gentoo I have sysvinit 2.86. YMMV?
    long time; /* know C? */
    Unprecedented performance: Nothing ever ran this slow before.
    Any sufficiently advanced bug is indistinguishable from a feature.
    Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
    The best way to accelerate an IBM is at 9.8 m/s/s.
    recursion (re - cur' - zhun) n. 1. (see recursion)

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. init adopts zombie process?
    By password636 in forum Linux Programming
    Replies: 4
    Last Post: 07-01-2009, 11:05 AM
  2. Fork Zombie Processes
    By valaris in forum Linux Programming
    Replies: 4
    Last Post: 09-05-2008, 09:16 AM
  3. zombie to exist after the termination of main program..
    By anilchowdhury in forum Linux Programming
    Replies: 0
    Last Post: 02-22-2008, 12:35 PM
  4. Fork => zombie => error
    By Morbo in forum Linux Programming
    Replies: 1
    Last Post: 12-08-2005, 11:53 AM
  5. zombie analysis
    By zedoo in forum Linux Programming
    Replies: 2
    Last Post: 10-07-2005, 10:15 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21