How to LSBize an Init Script

This is a short documentation about how to make an Init Script LSB-compliant. LSB-compliant init scripts need to:

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

Full informantion 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])

Most of this page has been pulled from a [ message by Petter Reinholdtsen] on [ Debian-devel].

This page is a quick and dirty draft. It is based on the content in [ LSB 3.0, Chapter 20.3. Comment Conventions for Init Scripts]. Is it recommended to read if you want to know more.

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.

All sections except the description-sections are space separate lists.

Provides should list the name of this service, normally the script name but might also list the name of services it "replaces".

Required-Start are services needed to start this service. These services must start before this service. Required-Stop are services used by this service, and this service should stop before the listed services are stopped.

Should-Start are services that if present should start before this service, but this service can start if the listed services are missing. Should-Stop are services that if present should be stopped after this service.

Default-Start is the run levels where this service should be started by default, and Default-Stop is the run levels where this service should be stopped by default.

Description and short-description are fairly obvious.

For dependency tracking, the required- and should- are important, and the rest is unused. The default runlevels are used by 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"/system service names, listed in <URL:>. 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.

Frequent questions

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

Answer: There is header specified in the LSB allowing this to be expressed. It is allowed to add extra (X-) headers, so we could add this expression if needed.

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

Answer: There is no such standard-defined header. 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 ourself.

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.