Hi,
Костик Покотиленко wrote:
> > 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'.
> ===========
Thanks for digging up these details!
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
