Re: [Fwd: Re: dccifd: restart after signal 6]

[David Laight <david%l8s.co.uk@localhost>]

On Mon, Jun 08, 2009 at 11:00:28AM -0400, Christos Zoulas wrote:
> 
> | That you call abort() after writing to stderr in is emblematic of
> | the NetBSD problems.  It would be dicey to call syslog(), but simply
> | assuming that stderr has not been long since closed is at best far
> | too naive for anyone allowed to touch a libc source tree.
> 
> Well, I agree with you, but this is not the only function that prints
> errors to stderr in libc; and if stderr is closed, you could easily
> look at the backtrace in the debugger to find out what went wrong.

And they should all be nuked ....

Many years ago we spent ages locating a problem that was actually
a splurious printf() call (it should have been an sprintf() call).
Since the generated data disn't include a '\n', and stdout is line
buffered, nothing untoward happenend until the code had run enough
times to fill the stdio buffer.
Then the data buffer was written to fd 1.
The program had earlier call close(1), and was reusing fd 1 as a
control pipe to another daemon - the text broke the protocol ....

Ok, if the program had done fclose(stderr) instead of close(1)
then it wouldn't have been a problem - but many daemons will
just do close(0); close(1); close(2); and assume that because
they don't access stdin, stdout or stderr that nothing else will.

        David

-- 
David Laight: david%l8s.co.uk@localhost