Re: Use FD_CLOEXEC on ListenSockets (was Re: Refactoring backend fork+exec code)

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tristan Partin <tristan(at)neon(dot)tech>
Subject: Re: Use FD_CLOEXEC on ListenSockets (was Re: Refactoring backend fork+exec code)
Date: 2023-08-28 20:52:15
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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 (

Attachment Content-Type Size
fix-syslogger-closesocket-errors.patch text/x-patch 937 bytes

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2023-08-28 21:05:57 Re: Eager page freeze criteria clarification
Previous Message Melanie Plageman 2023-08-28 20:30:15 Re: Eager page freeze criteria clarification