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

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Use FD_CLOEXEC on ListenSockets (was Re: Refactoring backend fork+exec code)
Дата
Msg-id b8fdd580-90f7-6b52-2aa9-b7585f6d34a6@iki.fi
обсуждение исходный текст
Ответ на Re: Use FD_CLOEXEC on ListenSockets (was Re: Refactoring backend fork+exec code)  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: Use FD_CLOEXEC on ListenSockets (was Re: Refactoring backend fork+exec code)  (Michael Paquier <michael@paquier.xyz>)
Список 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)

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: Eager page freeze criteria clarification
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Eager page freeze criteria clarification