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

[Markus Fischer]

I can confirm Mark's observation that "pidof $(which vi)" still does not 
work, at least when vi is running as normal user. However, when I run vi 
as root both pidof 3.06 and 3.07 work as expected.

Also my 2nd issue (which might have gone unnoticed because I didn't cc 
anybody) is still open. I'm going to paste it here again:

> I just could reproduce another case where pidof with the argument being
> a full path to a binary doesn't return a pid. It is not related to the
> argument being a symlink.
>
> This time it seems to be related to the program having been started with
> arguments but I don't see the unexpected behaviour with just any
> arguments, just some.
>
> For example, when having gdb running with "gdb --core=corefile" "pidof
> $(which gdb)" does not return a pid but when I start gdb with "gdb
> --quiet" "pidof $(which gdb)" behaves as expected.

I also noticed that as with vi above, when gdb was run as root "pidof 
$(which gdb)" works as expected with both 3.06 and 3.07.

- Markus


Am 22.03.23 um 16:38 schrieb 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?
>>
>
> I made a fix for this and have pushed it to the 3.07 branch of the SysV
> init repository. I'll publish a new version in a couple of days with
> this fix. There were some other changes to killall5 which are also in
> the queue, so this will fix a few issues.
>
> Would be great to have someone check the updated pidof and report if
> it's working okay for them too.
>
> - Jesse
>