[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]

Re: conserver eventually goes catatonic after SIGPIPE (on NetBSD)

Greg A. Woods woods@weird.com
Tue, 28 May 2002 15:10:59 -0700 (PDT)

[ On Sunday, May 26, 2002 at 00:10:06 (-0700), Bryan Stansell wrote: ]
> Subject: Re: conserver eventually goes catatonic after SIGPIPE (on NetBSD)
> right...no SIGPIPE handler.  but, there is a SIGCHLD handler, which
> gets called when forked processes die.  i don't think this is a problem
> (yet, at least).

Conserver definitely needs a SIGPIPE handler -- unless it wants to die
unexpectedly every time it writes to a client that has disconnected
abnormally.  The kernel sends SIGPIPE to processes writing to closed
sockets just as it does to processes writing to closed pipes....

> looking at #2, you see it's calling waitpid() from ConsChat().
> ConsChat() is part of your patch.  the problem, i'm guessing, is that
> the waitpid() inside the while loop has a little bad logic.

Bummer.  I completely missed/ignored the SIGCHLD handler and its call to
waitpid() when I added mine, and then when I read the stack backtrace I
completely forgot about mine -- or rather I think I assumed that since
it waited explicitly for the just-forked chat pid there could be no

I've been looking at some way to fix this.  The ideal fix would be to
block SIGCHLD during the execution of the chat program.  However the
code currently supports systems without sigaction(2).  Is that
important?  I'll bet conserver won't even compile on systems without
sigaction() despite the fact that API alone is handled portably....

The alternative is to keep a list of chat child PIDs and walk through
them after SIGCHLD is caught too....  That's a bit more work, but still
easily doable (I've got similar code already tested and working for some
other applications).  It seems a little messier since it introduces
concurrency in the error handling for chat processes where they're
currently really more synchronous....

								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>