Bug#486826: multipathd: suspicious file descriptors

[Guido Günther]

Hi Ferenc,
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.

>  * 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?

> File descriptor 3, hanging on the PID file, is also mildly suspicious.
This looks o.k. - see pidfile_create().

> /dev/xvda1 is the only block device in the system (besides the ramdisks),
> but that should not be multipathed.  Oh well, maybe multipathd can't know this.
No it can't.

> 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. Multipathd doesn't
close all fds like:

  for (i=getdtablesize();i>=0;--i)
    close(i);

some maybe this leaked in too?
Cheers,
 -- Guido