Bug#486826: multipathd: suspicious file descriptors
Ferenc Wagner
wferi at niif.hu
Thu Jun 19 16:45:27 UTC 2008
Guido Günther <agx at sigxcpu.org> writes:
> On Wed, Jun 18, 2008 at 02:22:41PM +0200, Ferenc Wagner wrote:
>
>> Of these 1,2 and 5 looks rather suspicious to my untrained eyes:
>>
>> * Shouldn't a daemon process always use /dev/null as stdin/stdout/stderr?
>
> multipathd uses /dev/console to output messages if necessary. See
> daemonize in the code. I'm not seeing anything really wrong with this.
Hi Guido,
Probably nothing really wrong, but multipathd is the only daemon on my
system which keeps /dev/console open. And anything output there is
almost guaranteed to go unnoticed. It's what syslog is for, and
indeed multipathd logs there. Then what is this for? Oh well.
>> * And why does it keep /var/lib/dpkg/triggers/File open? That's dpkg's
>> business exclusively, isn't it?
>
> Yes - and I'm not sure where this comes from. Could this be a bug in
> dpkg not setting close-on-exec for that file and we inherit this via
> fork/exec?
I also thought something like that.
>> File descriptor 3, hanging on the PID file, is also mildly suspicious.
>
> This looks o.k. - see pidfile_create().
Right, I've never seen a daemon keeping a lock on its PID file, but
sure, why not.
>> The sockets seem reasonable (based on /proc/net/unix), but how could I find out
>> what the pipe is for? /proc/*/fd reveals writers only.
>
> No idea. Does this persist if you restart multipathd.
Meanwhile I rebooted the machine a couple of times, and things look
different:
lr-x------ 1 root root 64 2008-06-19 18:22 0 -> /dev/null
l-wx------ 1 root root 64 2008-06-19 18:22 1 -> /dev/console
l-wx------ 1 root root 64 2008-06-19 18:22 2 -> /dev/console
l-wx------ 1 root root 64 2008-06-19 18:22 3 -> /var/run/multipathd.pid
lrwx------ 1 root root 64 2008-06-19 18:22 4 -> socket:[5023]
lr-x------ 1 root root 64 2008-06-19 18:22 5 -> /dev/xvda
lrwx------ 1 root root 64 2008-06-19 18:22 6 -> socket:[5025]
No pipe, and one socket less.
> Multipathd doesn't close all fds like:
>
> for (i=getdtablesize();i>=0;--i)
> close(i);
>
> some maybe this leaked in too?
Looks very much like that. This can be a dpkg bug, which doesn't
affect the daemons that close all file descriptors on startup.
Can you reproduce it, btw? Maybe we should reassing this bug. If I
purge/reinstall multipath-tools, they are back again:
lr-x------ 1 root root 64 2008-06-19 18:31 0 -> /dev/null
l-wx------ 1 root root 64 2008-06-19 18:31 1 -> /dev/console
l-wx------ 1 root root 64 2008-06-19 18:31 2 -> /dev/console
l-wx------ 1 root root 64 2008-06-19 18:31 26 -> pipe:[7468]
l-wx------ 1 root root 64 2008-06-19 18:31 3 -> /var/run/multipathd.pid
lrwx------ 1 root root 64 2008-06-19 18:31 4 -> socket:[7757]
lr-x------ 1 root root 64 2008-06-19 18:31 5 -> /var/lib/dpkg/triggers/File
lr-x------ 1 root root 64 2008-06-19 18:31 6 -> /dev/xvda
lrwx------ 1 root root 64 2008-06-19 18:31 7 -> socket:[7758]
lrwx------ 1 root root 64 2008-06-19 18:31 8 -> socket:[7760]
Okay, a looked into this. On a reinstall, this is the FD set of dpkg
and multipath-tools' postinst spawned by it directly:
lrwx------ 1 root root 64 2008-06-19 18:38 0 -> /dev/pts/2
lrwx------ 1 root root 64 2008-06-19 18:38 1 -> /dev/pts/2
lrwx------ 1 root root 64 2008-06-19 18:38 2 -> /dev/pts/2
l-wx------ 1 root root 64 2008-06-19 18:38 26 -> pipe:[8973]
lrwx------ 1 root root 64 2008-06-19 18:38 3 -> /var/lib/dpkg/lock
l-wx------ 1 root root 64 2008-06-19 18:38 4 -> /var/lib/dpkg/updates/tmp.i
lr-x------ 1 root root 64 2008-06-19 18:38 5 -> /var/lib/dpkg/triggers/File
lrwx------ 1 root root 64 2008-06-19 18:38 6 -> /var/lib/dpkg/triggers/Lock
l-wx------ 1 root root 64 2008-06-19 18:38 7 -> /var/log/dpkg.log
lr-x------ 1 root root 64 2008-06-19 18:38 8 -> /var/lib/dpkg/diversions
lrwx------ 1 root root 64 2008-06-19 18:38 0 -> /dev/pts/2
lrwx------ 1 root root 64 2008-06-19 18:38 1 -> /dev/pts/2
lrwx------ 1 root root 64 2008-06-19 18:38 2 -> /dev/pts/2
lr-x------ 1 root root 64 2008-06-19 18:38 255 -> /var/lib/dpkg/info/multipath-tools.postinst
l-wx------ 1 root root 64 2008-06-19 18:38 26 -> pipe:[8973]
lr-x------ 1 root root 64 2008-06-19 18:38 5 -> /var/lib/dpkg/triggers/File
The pipe and the File trigger leaked through, but nothing else.
I guess it's safe to reassing this bug to dpkg. BUT I still can't see
the origin of the third socket. Is that used by multipathd
internally?
--
Thanks,
Feri.
More information about the pkg-lvm-maintainers
mailing list