Guido Günther <[EMAIL PROTECTED]> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
