[lsb-discuss] Init Script additions and changes

Tobias Burnus tobias.burnus at physik.fu-berlin.de
Mon May 12 14:31:41 PDT 2003


Hi,

below I outline my proposed changes (which are included in the current
Work in Progress, http://www.linuxbase.org/spec/wip/wip/sysinit.html,
unless otherwise stated). The most things were encountered with the
administration of inhouse appliactions/scripts, thus these changes are
from ISV and system administrator point of view rather than from a
distribution perspective.
(For the curious, we use Debian Woody and SuSE 8.2.)


[bug 677737] Exit status for killproc, start_daemon, pidofproc
I run into the problem that Debian's pidofproc returns always the exit
code "0" (even if no program is running) and that SuSE's killproc returns
a "7" (lsb "status": "not running") even if it has stopped ("killed").
Therefore, the exit codes which the init-script has to return, should also
be returned by killproc, start_daemon, and pidofproc.
They may though restrict themselves to 0 and != 0.
(Exact wording, see WIP.)


[bug 677752] Should-Start/Should-Stop
The gLSB 1.3 highlighted that the current scheme is not sufficient for the
use by distributions since something like Should-{Start,Stop} is missing.
The UnitedLinux and SuSE bases systems have now
X-UnitedLinux-Should-Start. Thus I thought one could introduce this handy
option to the gLSB, since no program can rely on these weak dependencies.
The question is: Should there be still a footnote similar to the gLSB1.3
(http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/initscrcomconv.html#AEN26056)
or should the distributional support of this option be made manditory at
some point, i.e. one should warn the distribution vendors already.
(Exact current wording, see WIP)
(I seek comments regarding the notice: Do we want to force the support
this in future or not?)


[bug 677739] [Enhancement] pathname for killproc/pidofproc
Most distributions support the use of the pathname right away.
The advantage of passing the pathname instead of the basename is that the
killproc or the pidofproc script can do some clever testing of
/proc/<pid>/{cmd,exe} instead of relying on the basename for this.
Since the gLSB conform program should save their PID in
/var/run/<basename>, distributions can still use
  cat /var/run/`basename $PATHNAME`
Using the basename is still supported.
(See WIP)


[-p pidfile] for killproc and pidofproc
This allow one to specify a different PID file which should be checked.
This makes sense if I have a daemon started twice with different options.
For some reasons, I forgot start_daemon, which needs to check whether the
program is already running; thus a start_daemon -p <pidfile> might be
useful to.
(see WIP)


init script action: try-restart
This restarts the service, but it doesn't start it, if it is not running.
(This is implemented in SuSE/UnitedLinux and since it is optional it
doesn't hurd. See WIP)



Problems that I encountered, but that haven't found their way into a spec
yet. I'd like to hear some suggestions about those?

- 677745 - Should a pid file be deleted by killproc?

- 677744 - the behaviour of start_daemon is currently unclear
If one starts a perl script. Some start_daemons check only the PID file,
others (Debian's) /proc/<pid>/exe and others (SuSE's) also /proc/<pid>/cmd
This causes a perl daemon to be started twice on Debian and only once
(wished behaviour) on SuSE/UL.
I think SuSE's way is more correct, but I don't want to force the use of
/proc/<pid>/cmd.


- How should pidofproc and thus killproc work if there are multiple
programs running (multiple pids found in basename.pid or by other
means). This occures in priniple in the real world for AutoFS where one
daemon per mountpoint is started. Debian's pidofproc should only one PID
(= `pidof -s`) while SuSE's shows all (= `checkproc`, approx. = `pidof`).

- 677745 Should a pid file be deleted by killproc
If it still exist after the program had been TERMed or KILLed?

- 677749 Forking of programs which don't detach themself
Should the script fork (SuSE's does) or not (Debian's doesn't)?


With best regards,

Tobias





More information about the lsb-discuss mailing list