Comment 31 for bug 683640

Here's a run-down of the overall problem I'm seeing about how this is being done, implicitly relying on pidfiles:

Say you're running apache by init.d scripts (which Ubuntu does), and it uses status_of_proc to get the status:

status_of_proc -p /var/run/apache.pid $DAEMON $NAME

status_of_proc passes on it's arguments to pidofproc to verify it, reading -p's contents into $pid and attempts kill -0 $pid, if that succeeds, return code 0; failing that, ps "$pid", if success, return code 0, else return code 1.

Problem 1: It's checking the most unreliable piece of information possible. The PID a metadata file reports. Say Apache doesn't maintain it's own pid file, this could be reminents of an data that was never garbage collected.

Problem 2: PID file exists, is readable, kill -0 $pid succeeds, but the actual process is bash. Someone had logged in and obtained the same pid as the pid file mentioned. Oh, it's running just fine! Wrong.

status_of_proc takes two arguments, mandatory, which ultimately ends up being $DAEMON and $NAME, $NAME strictly used for log/visual representation, and $DAEMON being the process name to check for, yet $DAEMON is very seldomly used in any kind of verification of a process actually running. Especially when a pid file is provided in your current situation.

It's an implementation detail that is being ignored.

The 1 and only 1 piece of information that is most critical in checking if a process is running is one of the two possibilities:
1) The executable binary full path.
2) The process's name, in case it's forked into and parent closed, or the process sets it's processname, etc.

In the case of either of those 2, you can 100% guarantee a process is or is not running through standard common sense when writing the init script, to know how the daemon starts and what it's doing when it starts.

This is why I suggested another getopts option, -n "processname", or it could simply be taken from the first argument's $DAEMON value either way. But, verification that the pid matches the process should be part of the process, and if not, the pidfile is stale and fallback to checking if the process itself is actually running or not by it's name, and if not, THEN return a code representing the facts.