Bug#294066: Pid file handling broken

[Tore Anderson]

tags 294066 +patch
quit

* Patrick Caulfield

 multipathd is started very early on in the boot process. often
 before /var is mounted. PID files go in /var/run and if that dir
 doesn't exist the PID file handling is even more (and dangerously so)
 broken.

  I see that you've backed out the patch that originally caused me to
 submit this bug, as multipathd now is started later in the boot
 process.  Simply running multipath early and defer multipathd startup
 until later was a good solution to that problem, by the way.

  However, the pid file handling is still broken, but this time it is
 the init script that is the problem.  It looks for the file
 multipath-tools.pid, while it is actually called multipathd.pid.

  Trivial patch included:

--- /etc/init.d/multipath-tools~2006-02-11 13:58:34.0 +0100
+++ /etc/init.d/multipath-tools 2006-02-11 14:00:07.0 +0100
@@ -2,7 +2,7 @@
 
 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 DAEMON=/sbin/multipathd
-NAME=multipath-tools
+NAME=multipathd
 DESC=multipath daemon
 
 test -x $DAEMON || exit 0
@@ -36,7 +36,7 @@
echo .
;;
   *)
-   N=/etc/init.d/$NAME
+   N=/etc/init.d/multipath-tools
echo Usage: $N {start|stop|restart|reload|force-reload} 2
exit 1
;;


-- 
Tore Anderson



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#294066: Pid file handling broken

[Tore Anderson]

Package: multipath-tools
Severity: normal

  From the Debian changelog:

  * Use start-stop-daemon to control the multipathd daemon and do it's own
PID file handling (which is now commented out of the daemon itself)

  This is broken, as you do not use the --pidfile nor the --make-pidfile
 options of start-stop-daemon.  Why do you want this behaviour anyway?
 The normal way of doing it is to let the daemon itself create the pid
 file, and let start-stop-daemon know about it with the --pidfile
 option.  --make-pidfile isn't always reliable either - see the comments
 in start-stop-daemon's manual page.

  Putting the pidfile handling back into multipathd seemed to work just
 fine for me, and kept the multipath binary from complaining about not
 being able to signal multipathd.

-- 
Tore Anderson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#294066: Pid file handling broken

[Tore Anderson]

* Patrick Caulfield

  multipathd is started very early on in the boot process. often before /var
  is mounted. PID files go in /var/run and if that dir doesn't exist the PID
  file handling is even more (and dangerously so) broken.

  Good point, I must admit I didn't consider this (even though I was just
 finished writing a bug report about the libsysfs-in-/usr dependency,
 which never was sent as I discovered #293149..sheesh).

  I don't have any good solution to this problem, I'm afraid..

  Granted, the current situation isn't great but at least it allows
  multipathd to actually start on systems where /var is on a seperate
  partition to root - which was not the case previously.

  I still think just uncommenting the pidfile() call is bad, though.  I
 see the setsid() call is in that function, too..  I would think it would
 be better to make that function a tad more robust, so that it can work
 correctly when /var is available, and if not, just warn and continue.
 For instance:

--- main.c  2005-02-07 21:39:06.0 +0100
+++ main.c.tore 2005-02-07 21:46:52.0 +0100
@@ -744,9 +744,12 @@
exit(1);
}
 
-   file = fopen(DEFAULT_PIDFILE, w);
-   fprintf(file, %d\n, pid);
-   fclose(file);
+   if((file = fopen(DEFAULT_PIDFILE, w))) {
+   fprintf(file, %d\n, pid);
+   fclose(file);
+   } else
+   syslog(LOG_ERR, can't create pid file);
+
FREE(buf);
 }

Kind regards,
-- 
Tore Anderson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]