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. 
> 



This has been fixed upstream for the upcoming sysvinit 3.07. Would be
great to get some people testing it before we do an official reelase of
the 3.07 branch.

The updated pidof will now return an PID matches for a corresponding
executable or symbolic link. In other words, if /tmp/sleep is a symbolic
link to /usr/bin/sleep, then it doesn't matter which path name we use,
pidof will recognize both names go to the same real program and print
its PID.

- Jesse