svn commit: r205165 - head/lib/libc/gen

[Bruce Evans]

On Mon, 15 Mar 2010, Poul-Henning Kamp wrote:

> In message <20100316024446.A24853 at delplex.bde.org>, Bruce Evans writes:
>> On Tue, 16 Mar 2010, Bruce Evans wrote:
>
>> Due to the way that daemon() works, it is really an error to have any
>> open streams when it is called.  This is also undocumented, except
>> implicitly.  The errors are:
>> - unflushed output on stdout and stderr won't get flushed normally by
                                                              ^^^^^^^^
>>   the child.  stdout and stderr are redirected so it will go there if
>>   the child erroneously (?) uses these streams or simply calls exit()
>>   which will give the default flush.
>
> The in-core FILE buffers are copied in the child process, so they
> should most certainly not be flushed, but rather, as they correctly
> are, discarded, so that when the child causes the flush, the content
> is only output once.

Nope.

Even if the child causes the flush, the content of stdout and stderr
is not flushed normally since it is redirected to /dev/null.  Unflushed
input in stdin is handled more brokenly: although stdin is redirected
to /dev/null, input on it can still be read via stdin's buffer.
Inheriting unflushed input on other streams is a feature (unless these
streams are open on fd's 0-2; then these streams will have the same
corruption as std* streams open on their normal fd's 0-2).

As described in the unquoted part of my reply above, all streams should
be flushed by the parent before the fork(), so that they are flushed
normally.

daemon(3) has a lot to say about problems with open fd's 0-2, but it
says nothing about the extra problems with open streams on these
descriptors.  It documents as a feature that fd's above 2 are inherited
normally.  It also says too little about the implementation always
using fork() (it cross-references fork() but doesn't say that the
context is always a child context on successful completion).

Bruce