| Author |
zombie process questions
|
|
| jeniffer 2008-01-03, 1:44 am |
| 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?
| |
| Joachim Schmitz 2008-01-03, 7:32 am |
| "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
| |
| Vakayil Thobias 2008-01-03, 7:32 am |
|
"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
| |
|
| 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.
| |
| Casper H.S. Dik 2008-01-03, 1:23 pm |
| 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.
| |
|
| 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()?
| |
| Casper H.S. Dik 2008-01-03, 1:23 pm |
| 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.
| |
|
| 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.
| |
| Giorgos Keramidas 2008-01-04, 1:38 am |
| 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
| |
|
| 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...c?cvsroot=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.
| |
| Rainer Weikusat 2008-01-04, 7:38 am |
| Spoon <root@localhost> writes:
[...]
> 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?
All kernel 'objects' associated with a particular process are cleaned
up (insofar required) by the kernel on process termination.
| |
| Geoff Clare 2008-01-04, 1:27 pm |
| Spoon 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."
This was a mistake in the POSIX 2001 revision that happened when the
new _Exit() function from C99 was merged in. Previous versions of
POSIX required that _exit() not flush open streams, and the requirement
has been reinstated in the current draft of the next revision, which
says:
"The _Exit() and _exit() functions shall not call functions
registered with atexit() nor any registered signal handlers.
Open streams shall not be flushed. Whether open streams are
closed (without flushing) is implementation-defined."
(The observant will notice that the part about temporary files has been
removed. The requirements in this area are dealt with on the tmpfile()
page.)
> So what happens in Linux? in FreeBSD?
They don't flush streams in _exit(). Nor do any existing POSIX systems,
despite there being a loophole in the current revision that allows it.
Very many applications rely on _exit() not flushing.
--
Geoff Clare <netnews@gclare.org.uk>
|
|
|
|