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