Bug#448470: pidofproc falls back to pidof

[maximil...@credativ.de]

I suspect this is still not fixed. On a freshly installed Lenny system
of mine, portmap refuses to start stating "Already running". Adding
debug output to the init script shows that $(pidofproc portmap) returns
the PID of the shell running the init script ($$).

pidofproc falls back to pidof when there is no PID file, like on system
startup.

In my case, this leads to statd not being able to register with the
portmapper and my NFS mounts failing.

[Petter Reinholdtsen]

[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.

This is the working version:

pidofproc () {
local pidfile line i pids= status specified pid
pidfile=
specified=

OPTIND=1
while getopts p: opt ; do
case "$opt" in
p) pidfile="$OPTARG"; specified=1;;
esac
done
shift $(($OPTIND - 1))

if [ -z "${pidfile:-}" ]; then
pidfile=/var/run/${1##*/}.pid
fi

if [ -f "$pidfile" ]; then
read pid < "$pidfile"
if [ -n "${pid:-}" ]; then
if $(kill -0 "${pid:-}" 2> /dev/null); then
echo "$pid"
return 0
else
return 1 # program is dead and /var/run pid file exists
fi
fi
fi
if [ -x /bin/pidof -a ! "$specified" ]; then
/bin/pidof -o %PPID $1
status="$?"
[ "$status" = 1 ] && return 3 # program is not running
return 0
fi
return 4 # program or service is unknown
}

And this is the diff to the unstable version:

@@ -69,25 +71,31 @@
done
shift $(($OPTIND - 1))

- if [ -z "${pidfile:-}" ]; then
- pidfile=/var/run/${1##*/}.pid
+ base=${1##*/}
+ if [ ! "$specified" ]; then
+ pidfile="/var/run/$base.pid"
fi

- if [ -f "$pidfile" ]; then
+ if [ -n "${pidfile:-}" -a -e "$pidfile" ]; then
read pid < "$pidfile"
if [ -n "${pid:-}" ]; then
if $(kill -0 "${pid:-}" 2> /dev/null); then
echo "$pid"
return 0
+ elif ps "${pid:-}" >/dev/null 2>&1; then
+ echo "$pid"
+ return 0 # program is running, but not owned by this user
else
return 1 # program is dead and /var/run pid file exists
fi
fi
fi
if [ -x /bin/pidof -a ! "$specified" ]; then
- /bin/pidof -o %PPID $1
- status="$?"
- [ "$status" = 1 ] && return 3 # program is not running
+ status="0"
+ /bin/pidof -o %PPID -x $1 || status="$?"
+ if [ "$status" = 1 ]; then
+ return 3 # program is not running
+ fi
return 0
fi
return 4 # program or service is unknown

Happy hacking,
--
Petter Reinholdtsen

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Yves-Alexis Perez]

On Tue, Nov 25, 2008 at 06:07:40PM +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.

Hmhm yes that looks spurious. It's weird nobody noticed this before,
because it should break in many situations…

--
Yves-Alexis

[Arthur de Jong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've tested the above patch and it seems to solve the problem. It took me
a couple of times reading though /lib/lsb/init-functions to understand why
though (use of $specified is confusing).

Also this problem doesn't seem to show in all circumstances. It shows up
on systems with and /etc/network/interfaces like:
auto lo eth0
iface lo inet loopback
iface eth0 inet dhcp
but not with:
auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet dhcp
(the second was on a machine that was more recently installed)

- --
- -- arthur - ade...@debian.org - http://people.debian.org/~adejong --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJLQ8xVYan35+NCKcRAiTYAKDl7aNSWNLKs+1ubN0+HrVicdmgEACfT8ox
f5uXIUK2j7k2Z1fgAoht2UA=
=/UbY
-----END PGP SIGNATURE-----