1.how to see if a process is a zombie process.Can I see through ps?
2. How to explicitly write a program to create a zombie process?
Would I have to kill the parent using kill -9 getpid()  after forking?

[ Post a follow-up to this message ]

"jeniffer" <zenith.of.perfection@gmail.com> schrieb im Newsbeitrag
news:960bcc68-29b8-4a10-8eb0-fcc63c6cf537@u10g2000prn.googlegroups.com...
> 1.how to see if a process is a zombie process.Can I see through ps?
ps will show them as "<defunct>"

> 2. How to explicitly write a program to create a zombie process?
fork() and in the child exit().
Don't call wait() in the parent

> Would I have to kill the parent using kill -9 getpid()  after forking?
no, just not calling wait() in the parent should be sufficient.

Bye, Jojo

[ Post a follow-up to this message ]

"jeniffer" <zenith.of.perfection@gmail.com> wrote in message
news:960bcc68-29b8-4a10-8eb0-fcc63c6cf537@u10g2000prn.googlegroups.com...
> 1.how to see if a process is a zombie process.Can I see through ps?
> 2. How to explicitly write a program to create a zombie process?
> Would I have to kill the parent using kill -9 getpid()  after forking?

Please check the following link :
http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC13

[ Post a follow-up to this message ]

Joachim Schmitz wrote:

> fork() and in the child exit().

http://www.opengroup.org/onlinepubs...tions/exit.html

After the child calls exit(), the functions registered by the
parent with atexit() will be called. I think (??) it is
possible for some operations performed in these functions to
have an impact on the parent.

(This is where the _exit() function might be useful.)

Also I was wondering what happens when the parent has an open stream
(a FILE *) and forks, and the child exits. Will the stream still
function in the parent?

Regards.

[ Post a follow-up to this message ]

Spoon <root@localhost> writes:

>Also I was wondering what happens when the parent has an open stream
>(a FILE *) and forks, and the child exits. Will the stream still
>function in the parent?

If exit() is called in the child then there is the possibility that
utput buffers which are copied to the child on fork() are flushed
twice; some implementations also update seek pointers on file close.

(E.g., on Solaris "(head -1; head -1 ) < file" behaves exactly like
"head -2 < file" and different from "cat file | ....")

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

Casper H.S. Dik wrote:

> Spoon <root@localhost> wrote:
> 
>
> If exit() is called in the child then there is the possibility that
> output buffers which are copied to the child on fork() are flushed
> twice; some implementations also update seek pointers on file close.

Are the output buffers not flushed if the child calls _exit() instead
of exit()?

[ Post a follow-up to this message ]

Spoon <root@localhost> writes:

>Casper H.S. Dik wrote:
 
[vbcol=seagreen]
>Are the output buffers not flushed if the child calls _exit() instead
>of exit()?

Yes.  _exit() goes directly into the kernel and performs no userspace
cleanups.  (No _fini() processing, no atexit() handlers called, no
global destructors, etc)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

Casper H.S. Dik wrote:

> Spoon wrote:
> 
> 
> 
>
> Yes.  _exit() goes directly into the kernel and performs no userspace
> cleanups.  (No _fini() processing, no atexit() handlers called, no
> global destructors, etc)

I suppose the above stands for Solaris?

POSIX states:

"The _Exit() and _exit() functions shall not call functions registered
with atexit() nor any registered signal handlers. Whether open streams
are flushed or closed, or temporary files are removed is
implementation-defined."

So what happens in Linux? in FreeBSD?

Regards.

[ Post a follow-up to this message ]

On Thu, 03 Jan 2008 16:27:43 +0100, Spoon <root@localhost> wrote:
>Casper H.S. Dik wrote: 
>
> I suppose the above stands for Solaris?
>
> POSIX states:
>
> "The _Exit() and _exit() functions shall not call functions registered
> with atexit() nor any registered signal handlers. Whether open streams
> are flushed or closed, or temporary files are removed is
> implementation-defined."
>
> So what happens in Linux? in FreeBSD?

The source of all the systems you mentioned is freely available online,
so you can read it and find out easily.  If you are into this sort of
thing, then it may be interesting to skim through the Solaris sources
at the OpenSolaris web site:

http://cvs.opensolaris.org/

The search tool at the cvs.opensolaris.org site is _very_ fast and one
of the best ones I've used.  Give it a go, if you like learning about
the internals of Solaris.

The same holds true for FreeBSD.  The source of the exit(3) library
function is amazingly short in FreeBSD, and you can find its latest
version at:

http://cvsweb.freebsd.org/src/libc/libc/stdlib/exit.c

The normal exit(3) library function is mapped by the runtime linker to
the libc.so implementation of exit().  The libc.so exit() function then
does the following:

* It flushes any open file descriptors

* It updates internal FILE object attributes

* It calls any registered atexit() handlers

* It hands control over to the kernel, for _exit()

The _exit() symbol is a thin libc.so wrapper around the kernel function
sys_exit() which does the rest.

The files of the FreeBSD source tree which might be interesting, if you
are interested in even _more_ details include (but are probably not
limited only to) the following:

http://cvsweb.freebsd.org/src/libc/libc/stdlib/exit.c
http://cvsweb.freebsd.org/src/libc/libc/stdio/findfp.c
http://cvsweb.freebsd.org/src/libc/libc/stdio/fflush.c
http://cvsweb.freebsd.org/src/sys/kern/kern_exit.c

HTH,
Giorgos

[ Post a follow-up to this message ]

Giorgos Keramidas wrote:

> Spoon wrote:
> 
>
> The source of all the systems you mentioned is freely available online,
> so you can read it and find out easily.

For some very odd definition of "easily" :-)

For example, glibc code is definitely *not* what I consider an
easy read.

This is the code for exit():
http://sources.redhat.com/cgi-bin/c...t
=glibc

I don't find it obvious what happens to file descriptors and FILE
objects. Whatever happens should be in __libc_atexit() which /seems/ to
be an alias for _IO_cleanup() defined in libio/genops.c

int _IO_cleanup ()
{
/* We do *not* want locking.  Some threads might use streams but
that is there problem, we flush them underneath them.  */
int result = _IO_flush_all_lockp (0);

/* We currently don't have a reliable mechanism for making sure that
C++ static destructors are executed in the correct order.
So it is possible that other static destructors might want to
write to cout - and they're supposed to be able to do so.

The following will make the standard streambufs be unbuffered,
which forces any output from late destructors to be written out. */
_IO_unbuffer_write ();

return result;
}

I'll dig into the two above functions when I can.

This is the code for _exit() in Linux:
http://sources.redhat.com/cgi-bin/c...c?cvsroot=glibc

(Just a wrapper, like you said.)

Perhaps the file descriptors are closed by the kernel?

Regards.

[ Post a follow-up to this message ]