On mar, 2008-11-25 at 18:07 +0100, Petter Reinholdtsen wrote: > > [Philipp Kern] > > *argh* pidofproc returns the pid of the init script -> portmap does > > not start at all -> rpc.statd and other NFS daemons do not start. > > This affects lenny and severely breaks on-boot mounting of NFS > > shares. > > Hm, is this the /lib/lsb/init-functions implementation of pidofproc? > It seem to be completely useless if it behave as described here. > > I tested this in etch and unstable. It do not work this way in etch: > > % cat x > #!/bin/sh > . /lib/lsb/init-functions > pid=`pidofproc x` > echo $pid > % PATH=.:$PATH x > > % > > While in unstabe, the same script return a pid: > > % PATH=.:$PATH x > 18769 > % > > I would say this is a bug in lsb-base. Version 3.1-23.2etch1 work, > while 3.2-20 do not.
On ntp init, it uses -p $PIDFILE, so the last part is never executed.
I'm not sure if the behavior in intended in lsb-base. But
yes /etc/init.d/portmap and portmap will look the same way in:
ps -o %PID portmap
and this should be the case for all initscripts. We should better
protect us, I'll prepare another NMU with:
diff --git a/debian/init.d b/debian/init.d
index 7692c83..dc35d4b 100644
--- a/debian/init.d
+++ b/debian/init.d
@@ -30,7 +30,7 @@ fi
case "$1" in
start)
log_begin_msg "Starting portmap daemon..."
- pid=$( pidofproc portmap )
+ pid=$( pidofproc -p /var/run/portmap.pid portmap)
if [ -n "$pid" ] ; then
log_begin_msg "Already running."
log_end_msg 0
btw, in init-function, below pidofproc there's a comment:
# start-stop-daemon uses the same algorithm as "pidofproc" above.
so maybe we wouldn't need to check (using pidofproc) if the program is
running before. For example, ntp doesn't check and relies on
start-stop-daemon.
What do you think?
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
