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

[Matthew Vernon]

On 29/03/2023 12:37, Jesse Smith wrote:
>> Given subsequent discussion, could we instead use canonicalize_file_name
>> or realpath here instead? That would give us the "correct" path without
>> pidof having to think hard about symlinks et al.
> 
> 
> I'm open to the possibility. I'm curious as to what you see as the pros
> vs cons of changing the approach used by pidof?

Broadly, I think there is an expectation that
pidof $(which emacs)

works on Debian (et al) systems where alternatives are in use (or other 
setups with >1 symlink), regardless of which user is running the emacs 
(WLOG).

I think using realpath or canonicalize_file_name might simplify matters? 
But I've not gone poking through the code in detail, just this talk of 
more than one symlink confusing things made me think of these library 
functions.

Perhaps as an aside, on my system with 3.06-2, I see different behaviour 
depending on the user running the binary:

matthew at aragorn:~/junk$ ps waux | grep emacs
root      3905  0.0  0.0 165344  3976 tty1     T    Mar06   0:00 emacs 
/etc/mumble-server.ini
matthew   5149  0.0  1.0 453684 169224 ?       Ss   Feb11  61:26 emacs 
--daemon
matthew  13119  0.0  0.3 214776 50076 pts/19   S    Feb27   0:37 emacs 
accparse.py
matthew at aragorn:~/junk$ pidof emacs
13119 5149 3905
matthew at aragorn:~/junk$ pidof $(which emacs)
3905
matthew at aragorn:~/junk$ pidof $(readlink -f $(which emacs))
13119 5149

Here $(which emacs) -> /usr/bin/emacs -> /etc/alternatives/emacs -> 
/usr/bin/emacs-lucid

So the root process is picked up with pidof /usr/bin/emacs and the user 
processes by pidof /usr/bin/emacs-lucid.
pidof emacs picks up all three.

In each case /proc/pid/exe is (a deleted version of) /usr/bin/emacs-lucid

HTH,

Matthew