[Checked against Policy version 3.5.6.0, 2001-07-24]
I would like to suggest the following changes to Policy to make it more
in line with LSB 1.1. Most text is taken from:
http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/iniscrptact.html
http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/iniscrptfunc.html
Further changes to follow later.
10.3.2
Add a "status" argument with the following meaning:
"print the current status of the service"
Change Para 8 to read:
"The start, stop, restart, force-reload and status options should
be
supported by all scripts in /etc/init.d, the reload option is optional
Insert after para 10:
If the status command is given, 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 stopped
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
In the case of init script commands other than "status" (i.e.,
"start", "stop", "restart", "reload", and "force-reload"), the init
script must return an exit status of zero if the action described by
the argument has been successful. Otherwise, the exit status shall be
non-zero, as defined below. In addition to straightforward success,
the following situations are also to be considered successful:
restarting a service (instead of reloading it) with the
"force-reload" argument
running "start" on a service already running
running "stop" on a service already stopped or not
running
running "restart" on a service already stopped or not
running
In case of an error, while processing any init script action except
for "status", the init script must print an error message and return
one of the following non-zero exit status codes.
1 generic or unspecified error (current practice)
2 invalid or excess argument(s)
3 unimplemented feature (for example, "reload")
4 user had insufficient privilege
5 program is not installed
6 program is not configured
7 program is not running
8-99 reserved for future LSB use
100-149 reserved for distribution use
150-199 reserved for application use
200-254 reserved
[10.3.5]
Renumber existing text to 10.3.6
Replace Section with:
Each LSB-compliant init.d script must source the file
/lib/lsb/init-functions. This file must cause the following shell
script commands to be defined. This can be done either by adding a
directory to the PATH variable which defines these commands, or by
defining sh aliases. While the distribution-provided aliases may
choose to use bash extensions (at the distribution's option), the
LSB
init.d files themselves should only depend in /bin/sh features as
defined by POSIX.2.
start_daemon [-f] [-n nicelevel] pathname [args]
This runs the specified program as a daemon. start_daemon will check
to see if there is a program named "daemon" already running. If so, it
will not start another copy of the daemon unless the -f option is
given. The -n option specifies a nice level. See nice(1).
killproc basename [signal]
This stops the specified program. The program is found using the
algorithm given by pidofproc. If a signal is specified, the program
is
sent that signal. Otherwise, a SIGTERM followed by a SIGKILL after some
number of seconds is sent.
pidofproc basename
This function returns one or more pid(s) for a particular daemon.
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). Hence, LSB-complaint
applications who wish to use the pidofproc function in their init
scripts must store the pid in /var/run/basename.pid.
log_success_msg "message"
This requests the distribution to print a success message. The message
should be relatively short; no More than 60 characters is highly
desirable.
log_failure_msg "message"
This requests the distribution to print a failure message. The message
should be relatively short; no more than 60 characters is highly
desirable.
log_warning_msg "message"
This requests the distribution to print a warning message. The message
should be relatively short; no more than 60 characters is highly
desirable.
--
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.
