Bug#1033311: sysvinit-utils: pidof not always returning a pid,> when using the full path to a program

[Jesse Smith]

> Dear Maintainer,
> 
> Passing the full path of a binary to the pidof command does not always
> return a pid although the process is running and the man page of the
> pidof command explicitly notes that it can be used that way.
> 
> This might be related to the fact that all programs with which I tested
> this and which show this unexpected behaviour were symlinks (i.e.,
> "which <PROGRAM>" returned a symlink). However, on Debian Bullseye the
> behaviour is as I expected it.
> 
> 
> Steps to reproduce:
> * start vi
> * in another shell run "pidof vi" and "pidof $(which vi)"
> 
> Result:
> The first pidof invocation correctly returns a pid but the second
> invocation does not.
> 
> Expected result:
> Both invocations of pidof should return a pid. 
> 


I looked into this. And confirmed the behaviour.

It's due to a recent change which basically changes how we "stat" a
process name to avoid hanging in cases where a process is a zombie or
unresponsive.

Following the above example, running "pidof -z $(which vi)" will work
and return the process ID.

This is probably a bug. The pidof program was made to be more lax in its
checks to avoid hanging when a process is a zombie and, as a result,
it's also less particular when checking symbolic links.

- Jesse