defunct process

defunct process

Post by Vivek Kapadi » Tue, 13 Oct 1998 04:00:00



Hi,

I have a process which does not handle KILL signal. This process spawns
its own child. Now after I KILL the parent process, it shows up in 'ps'
with name <defunct>. Its child remains alive. The parent process only
gets killed when child terminates.

Can anybody please explain me what this <defunct> is?

Thanks in advance for help.

Vivek.

 
 
 

defunct process

Post by Zeke » Tue, 13 Oct 1998 04:00:00


This is a cogent way of saying zombie.  ;^)

The child process has important information to deliver
about it's exit status.  This information is delivered to
the parent, when the wait() system call is executed by
the parent.

If your really don't care about the death of a child,
perhaps changing signals before the exec() (or before
the fork() if there is no exec) will help.  That way
it's understood that the parent does not want exit
information.

Just how you code it depends on your version of UNIX.  
Your mileage may vary.  Blah, Blah, Blah.


> I have a process which does not handle KILL signal. This process spawns
> its own child. Now after I KILL the parent process, it shows up in 'ps'
> with name <defunct>. Its child remains alive. The parent process only
> gets killed when child terminates.

> Can anybody please explain me what this <defunct> is?


 
 
 

defunct process

Post by Scott G. Hal » Tue, 13 Oct 1998 04:00:00



> I have a process which does not handle KILL signal. This process spawns
> its own child. Now after I KILL the parent process, it shows up in 'ps'
> with name <defunct>. Its child remains alive. The parent process only
> gets killed when child terminates.

Of course, this is by design.  In UNIX all processes are children of one
single "ancester" process (for Sys-V, it is init).  If all of the resources
of a parent process have not been freed up yet, then it can't be removed
from the process table.  If a child process is using a resource that has
been created in the parent and is an automatic (allocated on the stack),
static or global (allocated in its data segment), then that portion cannot
be returned to the free pool to be overwritten by another process.

Quote:

> Can anybody please explain me what this <defunct> is?

It is a process that has ceased to run, but for which all of its resources
have not yet been freed.  You can't remove a process from the process table
if that entry contains pointers to resources that have yet to be freed up
or returned to the general pool.  Usually this happens when a parent process
has allocated I/O resources that are not yet finished, or are being used by
a child process.

--
Scott G. Hall
GTE Government Systems
North Carolina Systems Center

 
 
 

defunct process

Post by Raghavan V Parthasarath » Wed, 14 Oct 1998 04:00:00


Iam very much confused by this . I may have missed something
please correct me if iam wrong .



> > I have a process which does not handle KILL signal. This process spawns
> > its own child. Now after I KILL the parent process, it shows up in 'ps'
> > with name <defunct>. Its child remains alive. The parent process only
> > gets killed when child terminates.

> Of course, this is by design.  In UNIX all processes are children of one
> single "ancester" process (for Sys-V, it is init).  If all of the resources
> of a parent process have not been freed up yet, then it can't be removed
> from the process table.  If a child process is using a resource that has
> been created in the parent and is an automatic (allocated on the stack),
> static or global (allocated in its data segment), then that portion cannot
> be returned to the free pool to be overwritten by another process.

 After the fork  the child and parent run in their own address spaces   and the
automatic and global  data in one cannot affect the other .so any
  variable created in the parent  should not matter at all in the child .

Quote:

> > Can anybody please explain me what this <defunct> is?

> It is a process that has ceased to run, but for which all of its resources
> have not yet been freed.  You can't remove a process from the process table
> if that entry contains pointers to resources that have yet to be freed up
> or returned to the general pool.  Usually this happens when a parent process
> has allocated I/O resources that are not yet finished, or are being used by
> a child process.

     My understanding of a defunt process and its cause is this

When a child calls exit , If its parent is running and has not called
wait to accept the exit statusof the child , the child becomes a defunct
process

If the parent exits before the child .  init takes over as the parent
.and calls wait so the child does not become a defunct process in this
case .

 But the strange thing is sometimes i see a defunct process with  its
parent  as init .

> --
> Scott G. Hall
> GTE Government Systems
> North Carolina Systems Center


 
 
 

defunct process

Post by Barry Margoli » Wed, 14 Oct 1998 04:00:00




Quote:> But the strange thing is sometimes i see a defunct process with  its
>parent  as init .

I'll bet this is on AIX.  Some versions of AIX have a bug that causes this.

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.

 
 
 

defunct process

Post by Jon C. Snade » Wed, 14 Oct 1998 04:00:00






> > > But the strange thing is sometimes i see a defunct process with  its
> > >parent  as init .

> > I'll bet this is on AIX.  Some versions of AIX have a bug that causes this.

> Unless I misremember, traditional unix behavior is to allow the
> parent to die, and any children get adopted by init. I don't
> believe that it is a bug.

You remember correctly, but the bug that Barry is talking about is to
then have the child become a zombie when it terminates.  In systems
without this bug, init *does* wait for the children it inherits so that
the resources are freed and the child does not become a zombie.

Jon Snader

 
 
 

defunct process

Post by Scott G. Hal » Wed, 14 Oct 1998 04:00:00



> Iam very much confused by this . I may have missed something
> please correct me if iam wrong .


> > If a child process is using a resource that has
> > been created in the parent and is an automatic (allocated on the stack),
> > static or global (allocated in its data segment), then that portion cannot
> > be returned to the free pool to be overwritten by another process.

>  After the fork the child and parent run in their own address spaces and
> the automatic and global  data in one cannot affect the other .so any
>   variable created in the parent  should not matter at all in the child .

Not true!  When you fork() a child process, it too inherits any open file
descriptors (and associated pending I/O), process permissions, file creation
masks and resource limits, environment, signal handlers (including their
function addresses), all attached shared memory segments, memory mappings,
the controlling terminal, and copies of any global and static variables
(however they may be pointers to common shared data segments).  (see fork(2))

There are a number of calls you can make to detach the child process from
these resources, but until so, they need to remain.  Therefore, if the
parent has the resource, its process cannot be removed until all of its
resources are freed.

Quote:

>      My understanding of a defunt process and its cause is this

> When a child calls exit , If its parent is running and has not called
> wait to accept the exit statusof the child , the child becomes a defunct
> process

Wrong!  The child silently exits.  If the child is killed (from signal())
and it has pending I/O or a resource shared with another process, then it
will remain a zombie until the other process or I/O device driver finishes
with the resource.  In this case, a parent's wait() call will return, but
the child will become a zombie.

Quote:

> If the parent exits before the child .  init takes over as the parent
> .and calls wait so the child does not become a defunct process in this
> case .

>  But the strange thing is sometimes i see a defunct process with  its
> parent  as init .

The parent will be removed from the process table only when all of its
resources are able to be freed  (the resource attach counters reduced to
zero -- they are incremented when a call to fork() is made).  If a parent's
resources are no longer being addressed by the child, they can be returned
to their respective free pools, and the child is then adopted by the init
process (init becomes its parent).

--
Scott G. Hall
GTE Government Systems
North Carolina Systems Center

 
 
 

defunct process

Post by Thomas Rieche » Wed, 14 Oct 1998 04:00:00





> > But the strange thing is sometimes i see a defunct process with  its
> >parent  as init .

> I'll bet this is on AIX.  Some versions of AIX have a bug that causes this.

I have heard about this on solaris machines too.

My signal handler for child signals loops until there is no more zombie to
catch, because you got only one signal when several childs terminates on
the same time.

So, have you ever triggered init by SIGCHLD signal to call wait() for his
childs to get rid of those zombies?

Thomas

 
 
 

defunct process

Post by Thomas Rieche » Wed, 14 Oct 1998 04:00:00




> >  After the fork the child and parent run in their own address spaces and
> > the automatic and global  data in one cannot affect the other .so any
> >   variable created in the parent  should not matter at all in the child .

> Not true!  When you fork() a child process, it too inherits any open file
> descriptors (and associated pending I/O), process permissions, file creation
> masks and resource limits, environment, signal handlers (including their
> function addresses), all attached shared memory segments, memory mappings,
> the controlling terminal, and copies of any global and static variables
> (however they may be pointers to common shared data segments).  (see fork(2))

But in a different virtual memory space...

Quote:> There are a number of calls you can make to detach the child process from
> these resources, but until so, they need to remain.  Therefore, if the
> parent has the resource, its process cannot be removed until all of its
> resources are freed.

When a child exit and doesn't frees it resources, then it's the task for the
kernel to cleanup things like filedescriptors, memory allocation, open sockets.
Only resources that are not bound on a process like shared memory remains. To
tell the parent process the exit status, the kernel sends the SIGCHLD signal to
its parent. Afterwards the child process remains as an defunct-entry in the
process table. This is all done by the kernel!

Thomas

 
 
 

defunct process

Post by yong » Wed, 14 Oct 1998 04:00:00


Quote:> Of course, this is by design.  In UNIX all processes are children of one
> single "ancester" process (for Sys-V, it is init).  If all of the resources

Minor correction for you. "all processes" should be "all user processes". Some
system processes, page daemon, swapper, etc. are created by bootstrap just as
init is.

Yong

 
 
 

defunct process

Post by Zeke » Thu, 15 Oct 1998 04:00:00



> >   My understanding of a defunt process and its cause is this

> >   When a child calls exit , If its parent is running and has not called
> >   wait to accept the exit statusof the child , the child becomes a defunct
> >   process

> Wrong!  The child silently exits.  If the child is killed (from signal())
> and it has pending I/O or a resource shared with another process, then it
> will remain a zombie until the other process or I/O device driver finishes
> with the resource.  In this case, a parent's wait() call will return, but
> the child will become a zombie.

Are you suggesting that the signalled child some how avoids
executing the kernel's exit routine?  Every terminated process
becomes a zombie (SZOMB) regardless of how it terminated.

"Complete annihilation occurs when the parent subsequently uses
the wait system call".   - The Magic Garden Explained, p265

Well, better than the book is the code.  So which kernel
routine are you talking about that "a parent's wait() call will
return, but the child will become a zombie"?

 
 
 

defunct process

Post by Kcall104 » Sun, 18 Oct 1998 04:00:00


Even after a kill -9?
 
 
 

defunct process

Post by Peter van Hoo » Sun, 18 Oct 1998 04:00:00






>> > But the strange thing is sometimes i see a defunct process with  its
>> >parent  as init .

>> I'll bet this is on AIX.  Some versions of AIX have a bug that causes this.
>I have heard about this on solaris machines too.
>My signal handler for child signals loops until there is no more zombie to
>catch, because you got only one signal when several childs terminates on
>the same time.
>So, have you ever triggered init by SIGCHLD signal to call wait() for his
>childs to get rid of those zombies?

I have seen this on IRIX and HP-UX as well.  It seems to occur when
signal() is used to establish a handler for SIGCHLD.  Under System V
semantics, there is always a window between the re-establishment of
the handler and the return of the handler when a SIGCHLD occurs. If
during this window another SIGCHLD occurs, the handler is essentially
lost, so the system defaults to SIG_DFL, thusly leaving defuncts
after any child process exits.  When I saw this, the parent process
wasn't init, but I presume that after the original parent exits
the children are adopted by init.
I've only seen it on reasonably fast multiprocessor machines though.

Of course, one should use sigaction() in stead of signal().

peter

 
 
 

defunct process

Post by Peter van Hoo » Sun, 18 Oct 1998 04:00:00




>> Iam very much confused by this . I may have missed something
>> please correct me if iam wrong .


>> > If a child process is using a resource that has
>> > been created in the parent and is an automatic (allocated on the stack),
>> > static or global (allocated in its data segment), then that portion cannot
>> > be returned to the free pool to be overwritten by another process.

>>  After the fork the child and parent run in their own address spaces and
>> the automatic and global  data in one cannot affect the other .so any
>>   variable created in the parent  should not matter at all in the child .
>Not true!  When you fork() a child process, it too inherits any open file
>descriptors (and associated pending I/O), process permissions, file creation
>masks and resource limits, environment, signal handlers (including their
>function addresses), all attached shared memory segments, memory mappings,
>the controlling terminal, and copies of any global and static variables
>(however they may be pointers to common shared data segments).  (see fork(2))

You are wrong here.  Raghavan is right. The data spaces in parent and
child are completely independent.

Quote:>There are a number of calls you can make to detach the child process from
>these resources, but until so, they need to remain.  Therefore, if the
>parent has the resource, its process cannot be removed until all of its
>resources are freed.

This is not true. All of the resources are independent, except for
the shared memory segments and memory mappings.

Quote:

>>      My understanding of a defunt process and its cause is this

>> When a child calls exit , If its parent is running and has not called
>> wait to accept the exit statusof the child , the child becomes a defunct
>> process
>Wrong!  The child silently exits.  If the child is killed (from signal())
>and it has pending I/O or a resource shared with another process, then it
>will remain a zombie until the other process or I/O device driver finishes
>with the resource.  In this case, a parent's wait() call will return, but
>the child will become a zombie.

You are wrong again.  All processes become a zombie (defunct) process
when they die. They stay a zombie unless the parent has set SIG_IGN for
SIGCHLD or until the parent process has wait(2)ed for it. If the parent
has died before the child, init will wait(2) for it.
The only resources associated with a defunct process are a slot in the
process table, a rusage record and its exit status.

Quote:

>> If the parent exits before the child .  init takes over as the parent
>> .and calls wait so the child does not become a defunct process in this
>> case .

>>  But the strange thing is sometimes i see a defunct process with  its
>> parent  as init .
>The parent will be removed from the process table only when all of its
>resources are able to be freed  (the resource attach counters reduced to
>zero -- they are incremented when a call to fork() is made).  If a parent's
>resources are no longer being addressed by the child, they can be returned
>to their respective free pools, and the child is then adopted by the init
>process (init becomes its parent).

While it is true a process will be removed from the process table only
when its resources are freed, the parents' and childs' resources are
independent, so this can be done at any time.  The process slot of the
parent is only freed under the same conditions as the one of the
child.

Of course, some IPC resources such as shared memory segments remain in
the system even if there are no processes associated with them. They
have to be explicitly removed.

peter

 
 
 

defunct process

Post by Peter van Hoo » Mon, 19 Oct 1998 04:00:00



Quote:>Even after a kill -9?

You have left out too much of the context, so I'll have to speculate
on what you are asking:
There is no essential difference between a kill -9 and any other signal
that causes your program to terminate, except that SIGKILL cannot be
caught.
When such a signal is delivered to your process, all resources in use
by the process are freed by the kernel.

It doesn't matter how a process dies, it always becomes a defunct
process.  It is a natural state in the life cycle of all processes.  If
the parent of the process doesn't have SIG_IGN defined for SIGCHLD, and
it doesn't wait(2) for its children, the defunct process stays around
long enough for you to notice it.

peter

 
 
 

1. Defunct processes in Net Application

I have a communications program that creates a server
and then forks off children to handle connections.  The
problem I have is that once the children have finished
processing and exit, they become defunct processes
because they are waiting to report their status to the
parent.

I do not want to hold up the parent process waiting for
the child to exit.  Does anyone know how to use the
"wait" command to accomplish this.  I tryed using a
non-blocking "wait3" command but the defunct children
never went away.  I also tryed registering for a
SIGCHLD signal so that I would get interrupted when
a child had status to report.  Once interrupted I
did a wait3 to get the status of the child.  The SIGCHLD
interrupt caused the accept in my parent process to
return with an error.  I tryed ignoring the SIGCHLD
during the accept and then registering for it once the
accept was complete.  This didn't work either.  
The defunct processes never died.

Does anyone know how to solve this problem.  It seems
like it should be one of those simple things that I'm just
to ignorant to know about.

Thanks for your help,
Ann Ross

2. Had my redhat server been hajacked?

3. defunct processes ; killing

4. NEVER BUY HARDWARE from MICROMAX!!

5. S10 dtgreet and defunct process

6. error "/dev/tty Device not configured"

7. HELP please! why do I get defunct process

8. Apache on AIX4.1.4

9. Defunct Process on Solaris!!!!

10. Fork and Defunct Processes.

11. defunct process

12. Killing Defunct processes

13. Trouble with defunct process