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

[Jesse Smith]

On 2023-03-28 10:40 a.m., Mark Hindley wrote:
> On Thu, Mar 23, 2023 at 11:25:02AM -0300, Jesse Smith wrote:
>>> $ 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
>>
>> Okay, yes, this makes sense. The symbolic links are making multiple
>> jumps so it won't work. This is expected behaviour because there is no
>> executable running called /usr/bin/vi or /etc/alternatives/vi. Running
>> "pidof vi.tiny" would work. Or if /usr/bin/vi was a link to
>> /usr/bin/vim.tiny then "pidof $(which vi)" would work. pidof won't
>> follow aliases or symbolic links with multiple hops and different names.
> As Thorsten pointed out, multiple layers of symlinks is used in several places
> in Debian, not least the alternatives system.
>
> Shouldn't src/killall.c readproc() run readlink(2) until it gets the canonical
> executable path?
>
> Alternatively, if you really want to keep the behaviour change then pidof.8
> needs updating to reflect the new behaviour.
>
>
I would say the manual page is already accurate. It says symbolic links
to executables will return a match. This is true. It doesn't say
symbolic links to symbolic links will return a match. Though perhaps
this should be explicitly stated to clarify. I'll update the wording.

pidof isn't going to chase down multiple layers of symbolic links. If
the operator is dealing with situations like Debian's alternatives
system then they should just use the real name of the executable (gcc vs
cc, for example). Using a name that links to a name that links to
another name is likely to bite people.