Initscripts management proposal
I've been rather late with getting this proposal done (and my apologies
for that), but here it is. This is basically what I discussed at NYC,
with some additional details fleshed out. This is designed to
complement the existing sections defining the exit codes and arguments
to an init.d script.
- Ted
Initiscripts management proposal for the LSB
============================================
XXX Note: Lines that begin XXX are rational or commentary that should
be stripped (or moved to a rationale section) before publication.
It's simply easier for now to keep such notes in-line with the
documents.
XXX The idea is to put together a scheme which can provide much faster
(parallel) boot startups, but not require distributions should use it.
It should be compatible with with the old rc.d/init.d scheme.
Packages that need to execute a script at bootup and/or shutdown will
provide an init.d file. This file is either installed in some
standard directory (i.e. /etc/init.d --- which may be a symbolic link
to some other location), or we specify the use of an installation
shell script which copies the file to the correct. This is more
complicated; I would prefer a standard installation directory, which
may be a symlink if necessary.
In the init.d file, information about the shell script is delimited by
the strings "### BEGIN INIT INFO" and "### END INIT INFO". Inside
this block declarations shall take the form of "# <keyword>: [arg1]
[arg2] ..." The following keywords, with their arguments are defined
in this specification:
# Provides: <boot facility 1> [<boot facility 2> ...]
# Required-Start: <boot facility 1> [<boot facility 2> ...]
# Required-Stop: <boot facility 1> [<boot facility 2> ...]
# Default-Start: <run level 1> [<run level 2> ...]
# Default-Stop: <run level 1> [<run level 2> ...]
# Description: <multiline description>
Additional keywords may be defined in future LSB specifications.
Distributions may define local extensions by using the prefix
"X-<distribution name>" --- for example, "X-RedHat-foobardecl", or
"X-Debian-xyzzydecl".
An init.d shell script may declare using the "Requires: " header that
it must not be run until certain boot facilities are provided. This
information is used by the installation tool or the boot-time
boot-script execution facility to assure that init scripts are run in
the correct order.
In a multiline description, each continuation line must begin with a
'#' followed by a tab character. The multiline description is
terminated by the first line that does not match the '#','Tab'
continuation specification.
Installation of init.d files
============================
An init.d file is installed by copying it into /etc/init.d (which may
be a symlink to another location). This can be done by the package
installer. During the package's postinstall script, the program
"/usr/lib/lsb/install_initd" to configure the distribution's boot
script system to call the package's init.d file at the appropriate
time.
The install_initd program takes a single argument, the pathanme to the
/etc/init.d file. For example:
/usr/lib/lsb/install_initd /etc/init.d/inet
There should be a tool available to the user (ala RedHat's chkconfig)
which can be used by the system administrator to easily manipulate at
which init levels a particular init.d script is started or stopped.
This specification currently does not specify such an interface,
however. (XXX should it?)
Facility names
==============
Facility names that begin with a dollar sign ('$') are system facility
names, defined by the LSB, and MUST be provided by distributions. LSB
applications should not provide system facilities. This document
defines the following system facility names:
$local_fs all remote filesystems are mounted
$network low level networking (ethernet card; may
imply PCMCIA running)
$named named is operational
$remote_fs all remote filesystems are mounted (note
in some cases /usr may be remote. Most
applications that care will probably
require
both $local_fs and $remote_fs)
$syslog system logger is operational
$netdaemons all network daemons are running
Other system facilities may be defined by other LSB applications.
Facility names may also be init.d script names, although LSB
applications SHOULD NOT use script names, especially script names which
are provided by distributions, as these may not necessarily be the same
across different distributions.
Script names
=============
Since the init.d scripts must live in a single directory, they must be
come from a single namespace. Three means of assigning names from
this namespace are available:
1) Assigned namespace. This namespace consists of names which
only use the character set [a-z0-9]. This space is
desireable for scripts which system administrators may
often wish to run manually: e.g., "/etc/init.d/named
restart"
In order to avoid conflicts these names must be reserved
through the LANA (Linux Assigned Names/Numbers
Authority).
Commonly used names shall be reserved in advance;
developers for projects should be encouraged reserve
names
from LANA, so that each distribution can use the same
name, and to avoid conflicts with other projcts.
2) Hierarchical namespace. This namespace consists of scripts
names which look like this: <hier1>-<hier2>-...-<name>,
where name is again taken from [a-z0-9], and where
there may be one or more <hier-n> components. <hier1>
may either be a [a-z0-9] name assigned by the LANA, or
it may be owners' DNS name in lower case, with at
least one '.'. I.e., "debian.org",
"staroffice.sun.com", etc.
3) Reserved namespace. This namespace consists of script names
which begin with the character '_', and is reserved for
distribution use only. This namespace should be used
for core packages only, and in general use of this
namespace is highly discouraged.
In general, if a package or some system function is likely to be used
on multiple systems, the package developers or the distribution SHOULD
get a registered name through LANA, and disrtibutions should strive to
use the same name whenever possible. For applications which may not
be "core" or may not be commonly installed, the hierarchical namespace
may be more appropriate. An advantage to the hierarchical namespace
is that there is no need to consult with the LANA before obtaining an
assigned name.
Obviously, short names are highly desireable, since many system
administrators like to use them to manually start and stop services.
Given this, they should be standardized on a per-package basis. This
is the rationale behind having a LANA organization to assign these
names. The LANA may be called upon to handle other namespace issues,
such as package/prequiresites naming (which I'm sure will be a hot
political topic, but essential to make prerequisites to work
correctly).
This specification shall pre-define the following script names as:
apmd atd crond dhclient dhcpcd gpm halt identd inet
httpd kudzu klogd lpd mcserv named nfs nfslock pcmcia
portmap random routed rstatd rusersd rwhod sendmail smb
snmpd sshd syslog xfs xntpd ypbind
XXX Note: we don't have to agree exactly how all of these scripts
work. This is true especially of the low-level system names such as
syslog and klogd. If some distributions put both in syslog, and some
separate them out, this isn't a big deal; we just need to reserve the
names.
XXX Some of these packages, such as sshd, aren't currently being
distributed by distributions, but may in the future. For those we
need more definition, but it's still not much more than saying which
package they are associated with.
Functions
=========
Each LSB complaint init.d script must source the file
/usr/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 bash 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.
[ Same as sysvinit package ]
pidofproc basename
This finds the pid(s) for a particular daemon. If an
entry is found in /var/run/basename.pid, then that
value is returned. If not, first the "pidof" program
is used to try to find the daemon, and if that fails,
pidofproc will search the ps listing, looking for a
process name field of:
basename
(basename)
[basename]
basename:
[ Same as sysvinit package ]
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 desireable.
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 desireable.
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 desireable.
Reply to: