control: tags -1 +help
[ Adding to thread "apcupsd" Debian maintainer and "pidof" upstream
maintainer. ]
[2019-10-21 14:27] Martin von Wittich <martin.von.witt...@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.
