Re: Use FD_CLOEXEC on ListenSockets (was Re: Refactoring backend fork+exec code) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Use FD_CLOEXEC on ListenSockets (was Re: Refactoring backend fork+exec code)
Date
Msg-id b8fdd580-90f7-6b52-2aa9-b7585f6d34a6@iki.fi
Whole thread Raw
In response to Re: Use FD_CLOEXEC on ListenSockets (was Re: Refactoring backend fork+exec code)  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Use FD_CLOEXEC on ListenSockets (was Re: Refactoring backend fork+exec code)
List pgsql-hackers
On 28/08/2023 18:55, Jeff Janes wrote:
> Since this commit, I'm getting a lot (63 per restart) of messages:
> 
>   LOG:  could not close client or listen socket: Bad file descriptor
> All I have to do to get the message is turn logging_collector = on and 
> restart.
> 
> The close failure condition existed before the commit, it just wasn't 
> logged before.  So, did the extra logging added here just uncover a  
> pre-existing bug?

Yes, so it seems. Syslogger is started before the ListenSockets array is 
initialized, so its still all zeros. When syslogger is forked, the child 
process tries to close all the listen sockets, which are all zeros. So 
syslogger calls close(0) MAXLISTEN (64) times. Attached patch moves the 
array initialization earlier.

The first close(0) actually does have an effect: it closes stdin, which 
is fd 0. That is surely accidental, but I wonder if we should indeed 
close stdin in child processes? The postmaster process doesn't do 
anything with stdin either, although I guess a library might try to read 
a passphrase from stdin before starting up, for example.

-- 
Heikki Linnakangas
Neon (https://neon.tech)

Attachment

pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Eager page freeze criteria clarification
Next
From: Peter Geoghegan
Date:
Subject: Re: Eager page freeze criteria clarification