inetd fd leak?

[Doug Graham]

"inetd -e" does fix it for me, but LOG_NDELAY does not.

--Doug

Denys Vlasenko wrote:
> On Friday 04 September 2009 00:32, Denys Vlasenko wrote:
>   
>>> The  leak appears
>>> to be related to syslog.  For example, descriptor 6 was leaked, and 
>>> strace shows
>>> only these operations on that descriptor:
>>>
>>> socket(PF_FILE, SOCK_DGRAM, 0)          = 6
>>> fcntl64(6, F_SETFD, FD_CLOEXEC)         = 0
>>> connect(6, {sa_family=AF_FILE, path="/dev/log"}, 110) = 0
>>> send(6, "<27>Sep  3 17:49:45 inetd[1938]:"..., 75, MSG_NOSIGNAL) = 75
>>>
>>> After another run of bury.sh, the same thing happens on descriptor 7 
>>> (without 6
>>> being closed first).  The message being logged is this one:
>>>
>>> Sep  3 17:49:45 uml0 inetd[1938]: telnet/tcp: too many connections, pausing
>>>
>>> This is so totally weird that I figured it had to have something to do with
>>> vfork (just because vfork is so totally weird itself).  Replacing the 
>>> vfork in
>>> inetd.c with a fork instead does fix my leak.
>>>       
>> Hmmm. Try inetd with option -e. If it stops leaking, we found it.
>>     
>
> The tentative fix is to add LOG_NDELAY here in inetd.c:
>
>         if (!(opt & 4)) {
>                 /* LOG_NDELAY: connect to syslog daemon NOW.
>                  * Otherwise, we may open syslog socket
>                  * in vforked child, making opened fds and syslog()
>                  * internal state inconsistent.
>                  * This was observed to leak file descriptors. */
>                 openlog(applet_name, LOG_PID | LOG_NDELAY, LOG_DAEMON);
>                 logmode = LOGMODE_SYSLOG;
>         }
>
> --
> vda
>