[Bug 683640] Re: status_of_proc is returning incorrect error code
Psi-Jack
erenfro at gmail.com
Thu Oct 11 17:32:46 UTC 2012
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.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to lsb in Ubuntu.
https://bugs.launchpad.net/bugs/683640
Title:
status_of_proc is returning incorrect error code
Status in “lsb” package in Ubuntu:
Fix Released
Status in “lsb” source package in Lucid:
Fix Committed
Status in “lsb” source package in Natty:
Won't Fix
Status in “lsb” source package in Oneiric:
Won't Fix
Status in “lsb” source package in Precise:
Fix Committed
Status in “lsb” source package in Quantal:
Fix Released
Bug description:
Binary package hint: lsb
[Impact]
When status_of_proc is called with -p $PIDFILE and the service is not presently started, error code 4 is always returned because the process does not have the PID file existant until it is started, and it's deleted after stopping.
This fails LSB compliance because it should report 0 if the service is
stopped as expected.
[Test Case]
status_of_proc should /optionally/ check if a pid file exists or not, not make it mandatory to exist before throwing an error code. If pid file does exist, check it, verify it's associated with $DAEMON, and if not try to determine if the process is actually running under a different pid, if not, then return error code 0 because it is determined that it is /not/ running.
Error code 4 in LSB is reserved for total permanent failure that
requires manual intervention to correct. Such as, the process daemon
isn't executable due to permissions, or it tried to start but fails..
error code 4 is likely never used on checking status is very basic.
Either it's running, or it's not. That's all status_of_proc should
report, nothing more, nothing less.
[Regression]
Minimal, changes the behavior of checking against a pid file existance.
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: lsb-base 4.0-0ubuntu8
ProcVersionSignature: Ubuntu 2.6.32-26.48-server 2.6.32.24+drm33.11
Uname: Linux 2.6.32-26-server x86_64
Architecture: amd64
Date: Wed Dec 1 08:27:21 2010
InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2)
PackageArchitecture: all
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: lsb
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/683640/+subscriptions
More information about the foundations-bugs
mailing list