Linux Standard Base Core Specification 3.2 | ||
---|---|---|
<<< Previous | Chapter 20. System Initialization | Next >>> |
Conforming applications may install one or more initialization scripts (or init scripts). An init script shall be installed in /etc/init.d (which may be a symbolic link to another location), by the package installer.
Note: The requirement to install scripts in /etc/init.d may be removed in future versions of this specification. See Host-specific system configuration and Future Directions for further details.
During the installer's post-install processing phase the program /usr/lib/lsb/install_initd must be called to activate the init script. Activation consists of arranging for the init script to be called in the correct order on system run-level changes (including system boot and shutdown), based on dependencies supplied in the init script (see Comment Conventions for Init Scripts). The install_initd command should be thought of as a wrapper which hides the implementation details; how any given implementation arranges for the init script to be called at the appropriate time is not specified.
Example: if an init script specified "Default-Start: 3 4 5" and "Default-Stop: 0 1 2 6", install_initd might create "start" symbolic links with names starting with 'S' in /etc/rc3.d, /etc/rc4.d and /etc/rc5.d and "stop" symbolic links with names starting with 'K' in /etc/rc0.d, /etc/rc1.d, /etc/rc2.d and /etc/rc6.d. Such a scheme would be similar to the System V Init mechanism, but is by no means the only way this specification could be implemented.
The install_initd command takes a single argument, the full pathname of the installed init script. The init script must already be installed in /etc/init.d. The install_initd command will not copy it there, only activate it once it has been installed. For example:
The install_initd command shall return an exit status of zero if the init-script activation was successful or if the init script was already activated. If the dependencies in the init script (see Comment Conventions for Init Scripts) cannot be met, an exit status of one shall be returned and the init script shall not be activated.
When a software package is removed, /usr/lib/lsb/remove_initd must be called to deactivate the init script. This must occur before the init script itself is removed, as the dependency information in the script may be required for successful completion. Thus the installer's pre-remove processing phase must call remove_initd, and pass the full pathname of the installed init script. The package installer is still responsible for removing the init script. For example:
The remove_initd program shall return an exit status of zero if the init script has been successfully deactivated or if the init script is not activated. If another init script which depends on a boot facility provided by this init script is activated, an exit status of one shall be returned and the init script shall remain activated. The installer must fail on such an exit code so it does not subsequently remove the init script.
Note: This specification does not describe a mechanism for the system administrator to manipulate the run levels at which an init script is started or stopped. There is no assurance that modifying the comment block for this purpose will have the desired effect.
<<< Previous | Home | Next >>> |
Comment Conventions for Init Scripts | Up | Run Levels |