Hello,

Checked the archives for something like this, but they seem to deal
with detecting stdin being closed rather than stdout.

I have a program that opens a pipe for reading from a child process'
stdout. This child process works kind of like the "tail -f" behaviour.
The parent keeps select()ing on the pipe displaying the childs output
in a window. Now I can click on a "close" button in the GUI frontend
and it calls close() on the pipe. After that I want the child program
to exit. I wrote the following code

kill(file->childpid, SIGINT);
waitpid(file->childpid, &exitstatus, WNOHANG);

However, this causes the child to become a zombie obviously. However,
not doing the "kill" causes the child to keep running. Is there
anything I need to do in the child to detect if its stdout has been
closed? Can this be done via select()? I tried reversing the above
calls, but that didn't help either.

Thank you for any help or enlightenment,

Ian.

[ Post a follow-up to this message ]

"ivdneut@gmail.com" <ivdneut@gmail.com> writes:

>     kill(file->childpid, SIGINT);
>     waitpid(file->childpid, &exitstatus, WNOHANG);
>
> However, this causes the child to become a zombie obviously.

I don't see anything "obvious" about child becoming a zombie
(I bet it only *sometimes* becomes a zombie).

Removing WNOHANG should make child *never* become a zombie (unless
it blocks/ignores SIGINT).

> I tried reversing the above
> calls, but that didn't help either.

Of course it wouldn't. Are you "programming by coincidence"?
http://www.pragmaticprogrammer.com/...oincidence.html

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

Paul Pluzhnikov wrote:
> "ivdneut@gmail.com" <ivdneut@gmail.com> writes:
> 
>
> I don't see anything "obvious" about child becoming a zombie
> (I bet it only *sometimes* becomes a zombie).

>From waitpid(2) manual page on my Linux box:

If  a  child  as  requested by pid has already
exited by the time of the call (a so-called "zombie"  pro=AD
cess),  the  function  returns  immediately.

Since I just killed it, I figured I made it into a zombie at that point
because the parent is still alive and kicking.

>
> Removing WNOHANG should make child *never* become a zombie (unless
> it blocks/ignores SIGINT).

It doesn't but, unless I am misunderstanding something (very likely)
killing it while the parent still lives does.
 
>
> Of course it wouldn't. Are you "programming by coincidence"?
> http://www.pragmaticprogrammer.com/...oincidence.html

Only when all other options are exhausted ;-) Seriously, I figured that
doing waitpid() before the kill would prevent the zombie, because of
the cleanup waitpid does... of course I didn't think deep enough.

Still no idea how to make the child exit gracefully though. If I don't
do the kill, but do the waitpid, then the child just keeps running
until I kill it from the command line.

Thanks so far.

Ian.

[ Post a follow-up to this message ]

* "ivdneut@gmail.com" <ivdneut@gmail.com>
| Still no idea how to make the child exit gracefully though. If I
| don't do the kill, but do the waitpid, then the child just keeps
| running until I kill it from the command line.

When the pipe is closed in the parent, the child process should
eventually get an EPIPE error when writing/flushing its stdout, no?

Other than that, you could check in the child whether the write was
successful.

Or just loop a bit in the parent around the waitpid() call to give the
child a chance to get killed.  At least on my system (Suse 9.3) it
makes a difference if I sleep a bit before the waitpid() call.

My 0.01
R'

[ Post a follow-up to this message ]

"ivdneut@gmail.com" <ivdneut@gmail.com> wrote:
> Paul Pluzhnikov wrote: 
[snip][vbcol=seagreen]
>
> Since I just killed it, I figured I made it into a zombie at that point
> because the parent is still alive and kicking.
>

You didnt kill it, you just sent it the SIGINT signal. This does
not mean that the target processes recieved the signal nor that it
took any action at the time of the return from kill(). As someone
else pointed out; remove WNOHANG.

--
Torgny Lyon

[ Post a follow-up to this message ]

Ralf Fassel <ralfixx@gmx.de> writes:

>* "ivdneut@gmail.com" <ivdneut@gmail.com>
>| Still no idea how to make the child exit gracefully though. If I
>| don't do the kill, but do the waitpid, then the child just keeps
>| running until I kill it from the command line.

>When the pipe is closed in the parent, the child process should
>eventually get an EPIPE error when writing/flushing its stdout, no?

As long as you make sure that the child doesn't inherit the parent's
end of the pipe also.

Check what filedescriptors the child has still open.

If no signal handler for SIGPIPE is installed, the child would automatically
be killed with SIGPIPE.

Casper

[ Post a follow-up to this message ]

Torgny Lyon wrote:
> "ivdneut@gmail.com" <ivdneut@gmail.com> wrote: 
> [snip] 
>
> You didnt kill it, you just sent it the SIGINT signal. This does
> not mean that the target processes recieved the signal nor that it
> took any action at the time of the return from kill(). As someone
> else pointed out; remove WNOHANG.

You are right. I apologize. I misread that comment. This indeed solves
the problem. The WNOHANG was needed when the kill wasn't there. (Yes,
programming by coincidence, I will better my life ;)

Thank you all very much for the great help.

Ian.

[ Post a follow-up to this message ]

"ivdneut@gmail.com" <ivdneut@gmail.com> writes:
 
>
> If  a  child  as  requested by pid has already
> exited by the time of the call (a so-called "zombie"  pro_
> cess),  the  function  returns  immediately.

It returns immediately *after* having collected the child's
exit status and allowing the OS to completely get rid of the
child process (un-zombie-fying the child).

> Since I just killed it, I figured I made it into a zombie at that point

You are assuming that the child was scheduled to run, received
SIGINT, and was terminated (turned into zombie) *before* kill()
in the parent returned. These are unwarranted assumptions.

A correct solution (assuming child doesn't handle/block/ignore
SIGINT) is to kill() the child and then waitpid() *without* WNOHANG.

> Seriously, I figured that
> doing waitpid() before the kill would prevent the zombie, because of
> the cleanup waitpid does...

waitpid(..,WNOHANG) on a child that has not exited yet does not
and *can not* do any cleanup, and therefore doesn't prevent future
zombies.

> Still no idea how to make the child exit gracefully though.

See above.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

Casper H.S. Dik wrote:
> Ralf Fassel <ralfixx@gmx.de> writes:
> 
> 
>
> As long as you make sure that the child doesn't inherit the parent's
> end of the pipe also.
>
> Check what filedescriptors the child has still open.
>
> If no signal handler for SIGPIPE is installed, the child would automatical
ly
> be killed with SIGPIPE.

It does this, but this can take a while if the child has no data to
write to its stdout all the time. The child also exited (after it
became defunct) when I exited the parent. Anyway, it is solved now.

Thank you very much,

Ian.

[ Post a follow-up to this message ]