Hi Reco,

On 02/14/18 14:55, Reco wrote:

True. There's one tiny bit though - try

pidof -o %PPID -x /usr/sbin/sshd

and watch it output several pids as well.

Yes, indeed. If pidofproc would rely upon the pidfile only, then
there is no reason to call pidof.

And you don't have to spawn yet another sshd, a simple ssh login will

This was just an example to show how easy it is to break the
pgrep approach.

This particular part of pidofproc does not use pidof to get pid. It uses
pidof to guess the status of the process.

Indeed. /bin/pidof returns the process id of the service running
in a container, if the local service is not running. pidofproc
assumes it is running, even though there is no local pidfile.

2 bad things can happen here:

- the service in the container is killed
- the service on the host is not started

Using "/bin/pidof -c" the "foreign" root directory in the container
is detected and pidofproc returns less false positives, AFAICT. I
tried this on my servers in the office. RedHat EL uses "pidof -c"
as well, check /etc/rc.d/init.d/functions . I didn't examine other
Linux distros.

In the case of sshd pidofproc can break in a funny way indeed.

IMHO pidofproc (and hence the startup scripts) should rely upon not
loosing important information (the pid file).

True, but that particular part haven't wrote itself, someone did it on

I don't want to blame anybody, but I would like to get this fixed.
"pidof -c" does an additional check to verify the PID to return,
so this seems to be a safe workaround without introducing pgrep.


Reply via email to