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

[Markus Fischer]

```shell 1

$ type vi
vi is /usr/bin/vi
$ vi

```

```shell 2

$ cd ~/src/sysvinit-upstream/src/
$ ls -l pidof
lrwxrwxrwx 1 ivanhoe ivanhoe 8 Mar 22 14:56 pidof -> killall5
$ ./pidof vi
21945
$ ./pidof $(which vi)
$ ls -l $(which vi)
lrwxrwxrwx 1 root root 20 Jan 11 04:16 /usr/bin/vi -> /etc/alternatives/vi
$ ls -l /etc/alternatives/vi
lrwxrwxrwx 1 root root 17 Jan 11 04:16 /etc/alternatives/vi -> 
/usr/bin/vim.tiny
$ ls -l /usr/bin/vim.tiny
-rwxr-xr-x 1 root root 1713240 Jan 11 04:16 /usr/bin/vim.tiny

```

Am 23.03.23 um 15:03 schrieb 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
>>>