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

[Jesse Smith]

On 2023-03-22 8:31 a.m., Mark Hindley wrote:
> Markus,
>
> Thanks for this.
>
> On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote:
>> Package: sysvinit-utils
>> Version: 3.06-2
>> Severity: normal
>> X-Debbugs-Cc: none
>>
>> 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).
> Yes, I just tried with vim.basic which is not a symlink on my system and both
>
>  pidof vim.basic
>  pidof $(which vim.basic)
>
> work as expected.
>
>> However, on Debian Bullseye the
>> behaviour is as I expected it.
> So this appears to be a change in behaviour. I suspect this is an inadvertent
> side-effect of 0b695c7e0b1cac60ed77c56f224e296f023b652e.
>
> Jesse, or was it intentional?
>
It's a side-effect of the attempt to make pidof less prone to hanging
when checking sleeping processes and zombies. I'll look into it as the
symlink should probably work, or at least we should issue a warning.

- Jesse