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

[Jesse Smith]

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


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.