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