How to LSBize an Init Script

This is a short documentation about how to make an Init Script LSB-compliant based on the [ [Chapter 20 of the LSB 3.1]]. LSB-compliant init scripts need to:

and should also follow [ Debian Policy, chapter 9.4 Console messages from init.d scripts])

Full information on the actions (and return codes) that LSB scripts have to honor are available at [ LSB 3.1, Chapter 20.2. Init Script Actions]. Maintainers should review that section and review / adjust their init.d scripts accordingly.

Run-time dependencies

By documenting the run-time dependencies for init.d scripts, it becomes possible to verify the current boot order, and also to run boot scripts in parallel to speed up the boot process (This is on the [ TODO list for Etch])

Add a block like this in the init.d script (example based on xdebconfigurator):

# Provides:          xdebconfigurator
# Required-Start:    $syslog
# Required-Stop:     $syslog
# Should-Start:      $local_fs
# Should-Stop:       $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Generate xfree86 configuration at boot time
# Description:       Preseed X configuration and use dexconf to
#                    generate a new configuration file.

The block shown above has a special rigid format delimited by the lines


where all trailing spaces shall be ignored. On the other hand, all lines inside the block shall be of the form

# {keyword}: arg1 [arg2...]

and begin with a hash character '#' in the first column followed by one single space, except for the lines following the Description keyword. The following keywords are defined

Provides: boot_facility_1 [boot_facility_2...]

Required-Start: boot_facility_1 [boot_facility_2...]

Required-Stop: boot_facility_1 [boot_facility_2...]

Should-Start: boot_facility_1 [boot_facility_2...]

Should-Stop: boot_facility_1 [boot_facility_2...]

Default-Start: run_level_1 [run_level_2...],Default-Stop: run_level_1 [run_level_2...]

Short-Description: short_description

Description: multiline_description

For dependency tracking, the provides, required- and should- keywords are important, and the rest is unused. The default runlevels are used by a program to order the init scripts (e.g. insserv) to keep track of which rc#.d directory to update when a service is added for the first time, and should reflect the intent of the service.

There are some "virtual" facility names, listed in the [ [LSB 3.1]]. These are:


all local filesystems are mounted


low level networking (ethernet card; may imply PCMCIA running)


daemons which may provide hostname resolution (if present) are running. For example, daemons to query DNS, NIS+, or LDAP.


daemons providing ["SunRPC"]/ONCRPC portmapping service as defined in RFC 1833 (if present) are running all remote


filesystems are mounted. In some LSB run-time environments, filesystems such as /usr may be remote. Many applications that require $local_fs will probably require also require $remote_fs.


system logger is operational


the system time has been set, for example by using a network-based time program such as ntp or rdate, or via the hardware Real Time Clock.


facility supported by insserv to start a script after all the other scripts, at the end of the boot sequence.

Other (non-system) facilities may be defined by other applications. These facilities shall be named using the same [ conventions defined for naming init scripts].

Most of this section was originally based from a [ message by Petter Reinholdtsen] on [ Debian-devel].

Frequent questions

Question: Is it possible to start a given init script as late as possible?

Answer: yes, if you really want to do so, insserv recognises the $all virtual facility name such that the script will be executed at the end.

Question: Is it possible to add extra keywords?

Answer: If there is no current keyword you could use for your needs, the LSB allows for local extensions using the prefix X-. For example, X-Debian-foobardecl or X-Ubuntu-fastdecl.

Question: Is it possible to specify that a given script should start before another script?

Answer: There is no such standard-defined header. The LSB approach would be to get the second script to include your given script in its Required-Start arguments. Besides, we could define a debian specific extention to express this, but there is no implementation using such header, so we would have to implement it ourselves. Suse implemented X-Start-Before and X-Stop-After in insserv 1.09.0. Debian could and should use the same keywords.

Question: Shouldn't I wait until the Debian policy changes?

The Debian policy changes are slow to introduce even for things (for an example, see [ #291148]) which most maintainers agree are good since we have to wait first for many packages to do things in the same way before turning it into policy. Since we want to be LSB compliant, init.d scripts can be adjusted now to be LSB compliant.

Question: What is a "proper" exit status code? Looking at [ #208010,] this seems rather controversial. Non-zero exit codes might even cause breakage, and the LSB conflicts with Debian policy here.