Bug#926896: sysvinit-utils: pidof is unreliable

[Martin von Wittich]

I also just noticed this issue. We have a piece of code in our software 
that uses pidof to wait to apcupsd to start; I've reduced it to the 
following minimal working example:


#!/bin/bash

set -eu

systemctl restart apcupsd

#sleep 1

echo "Connecting to ups, please wait..."
START=$SECONDS

while pidof -s apcupsd >/dev/null
do
   if RES="$(apcaccess)"
   then
     if grep -q "^STATUS *: *COMMLOST" <<< "$RES"
     then
       break
     elif grep -q "^STATUS *: *ONLINE" <<< "$RES"
     then
       MODEL="$(sed -n 's/^MODEL *: *//p' <<< "$RES")"
       echo -e "Connection established:\n$MODEL"
       exit 0
     fi
   fi
   if [ $((SECONDS - START)) -ge 30 ]
   then
     break
   fi
   sleep 1
   echo -n .
done

echo "Connection failed!"


This worked fine for years, for example on a stretch server:

stretch-server ~ # ./test.sh
Connecting to ups, please wait...
Connection established:
Smart-UPS 750

But it doesn't work on a buster server:

buster-server ~ # ./test.sh
Connecting to ups, please wait...
Connection failed!

apcupsd is running, but for some reason, pidof isn't able to see it yet 
and therefore returns 1, which immediately terminates the loop. If you 
uncomment the sleep 1, it'll work:

buster-server ~ # ./test.sh
Connecting to ups, please wait...
Connection established:
Smart-UPS 750

Apparently the issue occurs only for very new processes...? The 
following script shows how pidof isn't able to see the process when it 
should be able to:


#!/bin/bash

set -eu
systemctl restart apcupsd
START=$SECONDS

ps aux|grep apcupsd
while true
do
   echo -n "pidof: "
   pidof -s apcupsd || echo
   [ $((SECONDS - START)) -ge 2 ] && break
   sleep 0.01
done
ps aux|grep apcupsd


Output on stretch, where pidof works fine:


stretch-server ~ # ./pidof.sh
root      6251  0.0  0.0  20420   180 ?        Ssl  14:57   0:00 
/sbin/apcupsd
root      6255  0.0  0.0   5128   800 pts/2    S+   14:57   0:00 grep 
apcupsd
pidof: 6251
[removed all duplicate lines...]
pidof: 6251
root      6251  0.0  0.0  20420   180 ?        Ssl  14:57   0:00 
/sbin/apcupsd
root      6380  0.0  0.0   5128   852 pts/2    S+   14:57   0:00 grep 
apcupsd

Output on buster:


buster-server ~ # ./pidof.sh
root     26609  0.0  0.0  87144  2060 ?        Dsl  15:00   0:00 
/sbin/apcupsd
root     26613  0.0  0.0   6424   884 pts/8    S+   15:00   0:00 grep 
apcupsd
pidof:
pidof:
pidof:
pidof:
pidof:
pidof:
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof:
pidof: 26609
pidof:
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof:
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
pidof: 26609
root     26609  0.0  0.0  87144  2060 ?        Ssl  15:00   0:00 
/sbin/apcupsd
root     26739  0.0  0.0   6424   884 pts/8    S+   15:00   0:00 grep 
apcupsd


There's always at least 4-6 empty "pidof:" lines at the beginning, so 
apparently pidof never works in the ~40-60ms after a process was 
launched. But there are almost always holes in the output further on, so 
it's also slightly unreliable afterwards.

-- 
Mit freundlichen Grüßen
Martin von Wittich

IServ GmbH
Bültenweg 73
38106 Braunschweig

Telefon: 0531-2243666-0
Fax: 0531-2243666-9
E-Mail: info at iserv.eu
Internet: iserv.eu

USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Martin Hüppe, Jörg Ludwig
Grundsätze zum Datenschutz: https://iserv.eu/privacy