Bug#926896: sysvinit-utils: pidof is unreliable

[Dmitry Bogatov]

control: tags -1 +help

[ Adding to thread "apcupsd" Debian maintainer and "pidof" upstream
  maintainer. ]

[2019-10-21 14:27] Martin von Wittich <martin.von.wittich at iserv.eu>
> Am 20.10.19 um 20:59 schrieb Dmitry Bogatov:
> > 
> > That sounds explainable. pidof() scans /proc directory, and it takes some
> > time for kernel to create entry there.
> [...]
> Even if there were, that wouldn't explain how ps is able to see the 
> process, while pidof is not. As far as I know, ps also gets this 
> information from /proc.

True.

> To verify my assumptions, I've adapted my test script as follows:

I adjusted script slightly (added -d option to first ls and replaced
"systectl" with "/etc/init.d" like following:

	#!/bin/bash

	set -eu
	/etc/init.d/apcupsd restart
	START=$SECONDS

	ps -f -C apcupsd
	PID="$(ps -o pid -C apcupsd --noheaders)"
	ls -d /proc/"$PID"

	while true
	do
	   echo -n "pidof: "
	   pidof -s apcupsd || echo
	   echo -n "ls: "
	   ls -d /proc/"$PID"
	   [ $((SECONDS - START)) -ge 2 ] && break
	   sleep 0.01
	done
	ps -f -C apcupsd

> So the /proc/26476 is there even when pidof doesn't see the process.
> >> But there are almost always holes in the output further on, so it's
> >> also slightly unreliabl afterwards.

and wasn't able to reproduce holes in the middle, but I did observed hole
at the beginning:

	Stopping UPS power management: apcupsd.
	Starting UPS power management: apcupsd.
	UID        PID  PPID  C STIME TTY          TIME CMD
	root     24352     1  0 22:51 ?        00:00:00 /sbin/apcupsd
	/proc/24352
	pidof: 
	ls: /proc/24352
	pidof: 24352
	[... all below is as expected ...]

Hole in beginning happened reproducibly, 100% of time.

> I had assumed that the problem should be easily reproducible with any
> other recently-started process, but that is apparently not the case:
> [...]
>
> Maybe systemd is somehow involved?

I tried to replace apcupsd with another servers on my box (tor,
apt-cacher-ng), but no holes happened with them.

I can't exclude that systemd is somehow related to holes in the middle
you observe, but hole in beginning is mysterious enough. Personally, I
am out of ideas: as far as I know (and I just web-searched), there is
only one way to get list of processes: scan /proc.

Jesse,
   any ideas how it could be possible for process to be discovered by
   ps(1), but not pidof(1)?

Dear apcupsd maintainer,
    any suggestions how "apcupsd" server process could be special, that
    it is not discovered by pidof(1) for some time after restart and,
    reportedly, even once in a while server is running?
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.