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

[Jesse Smith]

Could you give a full example of pidof not detecting the vi process?

I did all my testing as a regular user and both regular executables and
symlinks are showing up in pidof process listings. With and without
arguments.

The only thing I can think of which would throw this off would be if the
program being run was an alias. For example, if "vi" was an alias to
"vim" rather than a symlink.



On 2023-03-23 3:38 a.m., Markus Fischer wrote:
> 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
>>