```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
