Thread: dup(0) fails on Ubuntu 20.04 and macOS 10.15 with 13.0

dup(0) fails on Ubuntu 20.04 and macOS 10.15 with 13.0

From
Mario Emmenlauer
Date:
Dear All,

I've used PostgreSQL since version 9.x successfully on Linux, macOS
and Windows. Today I've upgraded from 12.3 to 13.0 and suddenly I can
not start the server any more on Ubuntu 20.04 (inside Docker on Ubuntu
18.04) and on macOS 10.15.

I get reproducibly the error:
2020-10-05 11:48:19.720 CEST [84731] WARNING:  dup(0) failed after 0 successes: Bad file descriptor
2020-10-05 11:48:19.720 CEST [84731] FATAL:  insufficient file descriptors available to start server process
2020-10-05 11:48:19.720 CEST [84731] DETAIL:  System allows 0, we need at least 58.
2020-10-05 11:48:19.720 CEST [84731] LOG:  database system is shut down

What makes this quite curious is that everything continues to work on
Ubuntu 18.04, and Windows with Visual Studio 2019.

I compile postgreSQL myself from source, but there are no patches or
tweaks involved (that I could think relevant for this problem).

I've searched for the particular error and understand that it is usually
caused by system limits on new files(?) But in my case, the failing
setups are relatively modern, powerful CI test machines, with virtually
no load at the time of test.

On Linux Ubuntu 20.04, `ulimit -n` shows `1048576` which seems also
relatively high (but must be the default, not changed by me).

Does this problem mean anything to anyone? I'm completely lost where
to go from here, or what to try next :-( Help would be greatly
appreciated!

All the best,

    Mario Emmenlauer



Re: dup(0) fails on Ubuntu 20.04 and macOS 10.15 with 13.0

From
Tom Lane
Date:
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?

            regards, tom lane



Re: dup(0) fails on Ubuntu 20.04 and macOS 10.15 with 13.0

From
Mario Emmenlauer
Date:
On 05.10.20 13:22, Mario Emmenlauer wrote:
> I've used PostgreSQL since version 9.x successfully on Linux, macOS
> and Windows. Today I've upgraded from 12.3 to 13.0 and suddenly I can
> not start the server any more on Ubuntu 20.04 (inside Docker on Ubuntu
> 18.04) and on macOS 10.15.
> 
> I get reproducibly the error:
> 2020-10-05 11:48:19.720 CEST [84731] WARNING:  dup(0) failed after 0 successes: Bad file descriptor
> 2020-10-05 11:48:19.720 CEST [84731] FATAL:  insufficient file descriptors available to start server process
> 2020-10-05 11:48:19.720 CEST [84731] DETAIL:  System allows 0, we need at least 58.
> 2020-10-05 11:48:19.720 CEST [84731] LOG:  database system is shut down
> 
> What makes this quite curious is that everything continues to work on
> Ubuntu 18.04, and Windows with Visual Studio 2019.
> 
> I compile postgreSQL myself from source, but there are no patches or
> tweaks involved (that I could think relevant for this problem).
> 
> I've searched for the particular error and understand that it is usually
> caused by system limits on new files(?) But in my case, the failing
> setups are relatively modern, powerful CI test machines, with virtually
> no load at the time of test.
> 
> On Linux Ubuntu 20.04, `ulimit -n` shows `1048576` which seems also
> relatively high (but must be the default, not changed by me).
> 
> Does this problem mean anything to anyone? I'm completely lost where
> to go from here, or what to try next :-( Help would be greatly
> appreciated!


I've just regression-tested 12.4 for the above problem, and I can now
isolate that 12.3 and 12.4 do _not_ give me above problem whereas 13.0
_does_ give me above problem. I tried also to isolate commits that may
be related, but could not find anything useful :-(

Help would be greatly appreciated!

All the best,

    Mario Emmenlauer



Re: dup(0) fails on Ubuntu 20.04 and macOS 10.15 with 13.0

From
Matthias Apitz
Date:
El día lunes, octubre 05, 2020 a las 04:49:27p. m. +0200, Mario Emmenlauer escribió:

> On 05.10.20 13:22, Mario Emmenlauer wrote:
> > I've used PostgreSQL since version 9.x successfully on Linux, macOS
> > and Windows. Today I've upgraded from 12.3 to 13.0 and suddenly I can
> > not start the server any more on Ubuntu 20.04 (inside Docker on Ubuntu
> > 18.04) and on macOS 10.15.
> > 
> > I get reproducibly the error:
> > 2020-10-05 11:48:19.720 CEST [84731] WARNING:  dup(0) failed after 0 successes: Bad file descriptor
> > 2020-10-05 11:48:19.720 CEST [84731] FATAL:  insufficient file descriptors available to start server process
> > 2020-10-05 11:48:19.720 CEST [84731] DETAIL:  System allows 0, we need at least 58.
> > 2020-10-05 11:48:19.720 CEST [84731] LOG:  database system is shut down
> > 
> > ...

Can you try to catch the situation starting the server under strace,
perhaps with '-f' to follow childs. And look into the output ('-o outfile') 
for the failing syscall.

    matthias

-- 
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин)
Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin)
Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)



Re: dup(0) fails on Ubuntu 20.04 and macOS 10.15 with 13.0

From
Mario Emmenlauer
Date:
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...).

All the best,

    Mario Emmenlauer