Bug#1033311: sysvinit-utils: pidof not always returning a pid,> when using the full path to a program
Jesse Smith
jessefrgsmith at yahoo.ca
Wed Mar 22 13:59:10 GMT 2023
> 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). However, on Debian Bullseye the
> behaviour is as I expected it.
>
>
> Steps to reproduce:
> * start vi
> * in another shell run "pidof vi" and "pidof $(which vi)"
>
> Result:
> The first pidof invocation correctly returns a pid but the second
> invocation does not.
>
> Expected result:
> Both invocations of pidof should return a pid.
>
I looked into this. And confirmed the behaviour.
It's due to a recent change which basically changes how we "stat" a
process name to avoid hanging in cases where a process is a zombie or
unresponsive.
Following the above example, running "pidof -z $(which vi)" will work
and return the process ID.
This is probably a bug. The pidof program was made to be more lax in its
checks to avoid hanging when a process is a zombie and, as a result,
it's also less particular when checking symbolic links.
- Jesse
More information about the Debian-init-diversity
mailing list