Re: [9fans] file descriptor leak

[Charles Forsyth <charles.forsyth@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]

On 16 February 2016 at 16:42, <lucio@proxima.alt.za> wrote:

> Then, it would be tempting to take the
>
>         dup(fd,0); close(fd);
>
> out to before the if(pid==0)...
>

the idea is to have fd (/dev/null in this case) be standard input in the
new process,
so it needs to follow the pid==0 test.

the "outside" command is one that wasn't distributed (I assume it bound a
separate #I interface
on /net.alt and set it up), so the code currently probably doesn't do
anything useful elsewhere.


> probably the file descriptor leak comes from dnresolve.c


you can cat /proc/$dnspid/fd
where dnspid is the process id one or more of the active dns processes,
to see which files are open, after the message appears.
if there are many /dev/null open, that suggests your idea was right.

i think you're right that it leaks an fd to /dev/null in that system call,
so
it should instead open /dev/null separately and assign fd before the call
and close it afterwards.

even so, i wonder if that's really what's happening in every case of "more
than N fds", because
the call to outside is only needed in the case that the udp under /net.alt
is being
used and an open there has failed. still, looking at the /proc/N/fd file
should help decide that.

[-- Attachment #2: Type: text/html, Size: 2588 bytes --]