Comment 29 for bug 683640

No, actually, I'm following the LSB standards to the T.

You are correct in the fact, a process COULD be run under a different name, and for those cases, status_of_proc should be able to be alerted to that name, such as -n "processname", but pid files being weighted more authority than an actual process list check is very much inaccurate and incorrect to check the actual status of a process to whether it's running or not.

The very point of status is to check whether a process is running or not running. If you go strictly by a pid file if specified, and that program dies and doesn't clean up it's mess of metadata files (which a pid file is technically a metadata file), and you only check that, then you are simply wrong. pid files barely even part of /the/ standards as shown:

If the status action is requested, the init script will return the following exit status codes.

0 program is running or service is OK
1 program is dead and /var/run pid file exists
2 program is dead and /var/lock lock file exists
3 program is not running
4 program or service status is unknown
5-99 reserved for future LSB use
100-149 reserved for distribution use
150-199 reserved for application use
200-254 reserved

Reference URL: http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

This is basically stating: If a pid file exists, check it, if it's running and the pid file exists and is accurate as the program expected is running, return 0.

HOWEVER,
If the pid file is missing or doesn't exist, check if the process is running by name or by binary name, if so, it's still running. Return 0
If the pid file exists and is NOT actually running, return 1

That's the root of the problem, misunderstanding of LSB init's standards, all of which you can easily and quickly get proper clarification from their website and from Freenode's #lsb channel which I have already done all the research and legwork into and why I continue to say you are wrong in this band-aid incorrect fix.