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: [email protected]
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
