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

[Mark Hindley]

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.

Mark