[lsb-discuss] gLSB: sysinit: clearify algorithm for determining status of programs

Tobias Burnus tobias.burnus at physik.fu-berlin.de
Wed Sep 3 13:35:58 PDT 2003

Hello again,

the gLSB 1.3 initfunctions.sgml contains:
"If an entry is found in /var/run/basename.pid, then that value is
 returned. Compliant implementations of the LSB may attempt other
 mechanisms for determining the pid(s), although this is not required
 (and not recommended, since a user can trick startup scripts by creating
 processes that appear to be system programs in the process list thus
 creating a potential security exposure)."

This explicily allows this: first checking for the pidfile and then,
if it doesn't exist, checking the /proc system (using e.g. pidof).

There are two possible reasons for the case that there is no pidfile
present: (a) the program doesn't use pidfiles (implicitly assumed above)
or (b) it is not running.

This makes trouble when a daemon is started twice with different
pid and coniguration files. My all ready cited example,
  /usr/sbin/sshd                                 (/var/run/sshd.pid)
  /usr/sbin/sshd -f /etc/ssh/sshd_config2 -p 123 (/var/run/zedv-sshd.pid),
shows that   pidof $BIN  ==  pidof /usr/sbin/sshd  has no chance to
discriminate those two. Considering that one can pass a basename instead of
a pathname to pidofproc and killproc, things are even worse. 

I therefore would like to prohibit the checking of other pids but those
given in the pidfile. My main problem is that at least three distributions
use the pidof fallback: RedHat, SuSE and Debian. Thus I'm a bit reluctant to
simply disallow this.

Therefore I would really appreciate to get some feedback from the

The current spec (gLSB 1.9-CVS) is now:
"Compliant implementations may (but should not) use other mechanisms
 besides those based on pidfiles."


More information about the lsb-discuss mailing list