Bug#926896: sysvinit-utils: pidof is unreliable

[Костик Покотиленко]

> So from what I gather, this means that procps's pidof has the problem
> described in this bug report?
>
> From my point of view the only way to solve this without reopening
> #719273 is to add a switch which recognizes D processes or not. Or
> adds some kind of timeout.
>
>
I don't think so, because:

1. Nowadays Fedora uses pidof from procps, it does not use neither stat()
not realpath(). Its source code has mention:

"avoiding stat(2) on NFS volumes doesn't make any sense anymore as this
reworked solution does not use stat(2) at all"
https://gitlab.com/procps-ng/procps/-/blob/master/pidof.c#L347

2. In Debian the intention was to resolve #719273, but it has next
statement:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719273#42
===========
Also, at the current time (and IIRC this wasn't the case when we submitted
the original patch), start-stop-daemon is a binary not a script, and it
doesn't call pidof or killall.  Instead it uses its own code, and that code
is subject to the same issue where it hangs on stuck NFS partitions.
Therefore, as it stands, applying this patch to 'pidof' will no longer
resolve the issue; similar changes would have to be made to 'killall'.
===========

#719273 is Wheezy times (reported 09 Aug 2013).

I don't know how this applies to recent systems. It probably does not apply
because of comment above and the fact that systemd now used (at least by
default) in place of sysvinit/start-stop-daemon.

Nonetheless, I wonder what switch to pidof from procps can break
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20200501/59b48591/attachment.html>