[ redirecting to -hackers ]
Mario Emmenlauer <mario@emmenlauer.de> writes:
> On 05.10.20 14:35, Tom Lane wrote:
>> Mario Emmenlauer <mario@emmenlauer.de> writes:
>>> I get reproducibly the error:
>>> 2020-10-05 11:48:19.720 CEST [84731] WARNING: dup(0) failed after 0 successes: Bad file descriptor
>> Hmph. That code loop assumes that stdin exists to be duplicated,
>> but maybe if it had been closed, you'd get this error.
>>
>> However, that logic hasn't changed in decades, and we've not heard
>> complaints about it before. Are you starting the server in some
>> unusual way?
> Replying to a very old thread here: I could indeed trace the problem of
> the failing `dup(0)` back to how we start the server! We start the
> server from an executable that closes stdin very early on, and this
> seems to lead to the problem.
> We solved it by not closing stdin. But for future reference, if other
> people may be affected by this, the code could probably be modified to
> revert to stdout or stderr or a temporary file in case stdin is not
> available (guessing here...).
Hm. I'm tempted to propose that we simply change that from dup(0) to
dup(2). Formally, that's just moving the problem around. In practice
though, there are good reasons not to close the server's stderr, ie you
will lose error messages that might be important. OTOH there does not
seem to be any obvious reason why the server should need valid stdin,
so if we can get rid of an implementation artifact that makes it require
that, that seems like an improvement.
regards, tom lane