Init Script Actions

Init Script Actions

Conforming applications which need to execute commands on changes to the system run level (including boot and shutdown), may install one or more init scripts. Init scripts provided by conforming applications shall accept a single argument which selects the action:


start start the service
stop stop the service
restart stop and restart the service if the service is already running, otherwise start the service
try-restart restart the service if the service is already running
reload cause the configuration of the service to be reloaded without actually stopping and restarting the service
force-reload cause the configuration to be reloaded if the service supports this, otherwise restart the service if it is running
status print the current status of the service


The start, stop, restart, force-reload, and status actions shall be supported by all init scripts; the reload and the try-restart actions are optional. Other init-script actions may be defined by the init script.

Init scripts shall ensure that they will behave sensibly if invoked with start when the service is already running, or with stop when not running, and that they do not kill similarly-named user processes. The best way to achieve this is to use the init-script functions provided by /lib/lsb/init-functions (see Init Script Functions)

If a service reloads its configuration automatically (as in the case of cron, for example), the reload action of the init script shall behave as if the configuration was reloaded successfully. The restart, try-restart, reload and force-reload actions may be atomic; that is if a service is known not to be operational after a restart or reload, the script may return an error without any further action.

Note: This specification does not define the concept of a package upgrade. Implementations may do different things when packages are upgraded, including not replacing an init script if it is marked as a configuration file, particularly if the file appears to have been modified since installation. In some circumstances, the init script may not be removed when the package is uninstalled. Applications should design their installation procedure and init scripts to be robust in the face of such behavior. In particular, init scripts should not fail obscurely if run in unexpected circumstances. Testing for the existence of application binaries before executing them is suggested.

If the status action is requested, 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 not running
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



For all other init-script actions, the init script shall return an exit status of zero if the action was 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:



In case of an error while processing any init-script action except for status, the init script shall print an error message and exit with a non-zero status code:


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



Error and status messages should be printed with the logging functions (see Init Script Functions) log_success_msg(), log_failure_msg() and log_warning_msg(). Scripts may write to standard error or standard output, but implementations need not present text written to standard error/output to the user or do anything else with it.