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
