There are two types of scripts in /etc/init.d:
Scripts executed directly by init. This is the case only during the boot process or if an immediate system shutdown is initiated (power failure or a user pressing Ctrl-Alt-Del). For IBM S/390 and zSeries systems, this is the case only during the boot process or if an immediate system shutdown is initiated (power failure or via “signal quiesce”).
All scripts are located in /etc/init.d. Scripts for changing the runlevel are also found there, but are called through symbolic links from one of the subdirectories (/etc/init.d/rc0.d to /etc/init.d/rc6.d). This is just for clarity reasons and avoids duplicate scripts (e.g., if they are used in several runlevels). Because every script can be executed as both a start and a stop script, these scripts must understand the parameters start and stop. The scripts also understand the restart, reload, force-reload, and status options. These different options are explained in Table 11.2. “Possible init Script Options”.
Table 11.2. Possible init Script Options
|restart||If the service is running, stop it then restart it. If it is not running, start it.|
|reload||Reload the configuration without stopping and restarting the service.|
|force-reload||Reload the configuration if the service supports this. Otherwise, do the same as if restart had been given.|
|status||Show current status of service.|
Links in each runlevel-specific subdirectory make it possible to associate scripts with different runlevels. When installing or uninstalling packages, such links are added and removed with the help of the program insserv (or using /usr/lib/lsb/install_initd, which is a script calling this program). See the manual page of insserv for details.
Below is a short introduction to the boot and stop scripts launched first (or last, respectively) as well as an explanation of the maintaining script.
Executed while starting the system directly using init. It is independent of the chosen runlevel and is only executed once. Here, the proc and pts file systems are mounted and the blogd (boot logging daemon) is activated. If the system is booted for the first time after an update or an installation, the initial system configuration is started.
The blogd daemon is a service started by boot and by rc before any other one. It is stopped after the actions triggered by the above scripts (running a number of subscripts, for example) are completed. The blogd daemon writes any screen output to the log file /var/log/boot.msg — but only if and when /var is mounted read-write. Otherwise, blogd buffers all screen data until /var becomes available. Further information about blogd can be obtained with man blogd.
The script boot is also responsible for starting all the scripts in /etc/init.d/boot.d with a name that starts with S. There, the file systems are checked and loop devices are configured if needed. The system time is also set. If an error occurs while automatically checking and repairing the file system, the system administrator can intervene after first entering the root password. Last executed is the script boot.local.
This script is executed when changing from single user mode to any other runlevel and is responsible for a number of basic settings, such the keyboard layout and initialization of the virtual consoles.
You can create your own scripts and easily integrate them into the scheme described above. For instructions about formatting, naming, and organizing custom scripts, refer to the specifications of the LSB and to the man pages of init, init.d, and insserv. Additionally consult the man pages of startproc and killproc.
|Creating Your Own init Scripts|
Faulty init scripts may freeze your machine. Edit such scripts with great care and, if possible, subject them to heavy testing in the multiuser environment. Some useful information about init scripts can be found in Section 11.2. “Runlevels”.
To create a custom init script for a given program or service, use the file /etc/init.d/skeleton as a template. Save a copy of this file under the new name and edit the relevant program and file names, paths, and other details as needed. You may also need to enhance the script with your own parts, so the correct actions are triggered by the init procedure.
The INIT INFO block at the top is a required part of the script and should be edited. See Example 11.1. “A Minimal INIT INFO Block”.
Example 11.1. A Minimal INIT INFO Block
### BEGIN INIT INFO # Provides: FOO # Required-Start: $syslog $remote_fs # Required-Stop: $syslog $remote_fs # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Description: Start FOO to allow XY and provide YZ ### END INIT INFO
In the first line of the INFO block, after Provides:, specify the name of the program or service controlled by this init script. In the Required-Start: and Required-Stop: lines, specify all services that need to be started or stopped, respectively, before the service itself is started or stopped. This information is used later to generate the numbering of script names, as found in the runlevel directories. Under Default-Start: and Default-Stop:, specify the runlevels in which the service should automatically be started or stopped. Finally, under Description:, provide a short description of the service in question.
To create the links from /etc/init.d/ to the corresponding runlevel directories (/etc/init.d/rc?.d/), enter the command insserv <new-script-name>. The insserv program evaluates the INIT INFO header to create the necessary links for start and stop scripts in the runlevel directories (/etc/init.d/rc?.d/). The program also takes care of the correct start and stop order for each runlevel by including the necessary numbers in the names of these links. If you prefer a graphical tool to create such links, use the runlevel editor provided by YaST, as described in Section 11.5. “The YaST Runlevel Editor”.
If a script already present in /etc/init.d/ should be integrated into the existing runlevel scheme, create the links in the runlevel directories right away with insserv or by enabling the corresponding service in the runlevel editor of YaST. Your changes are applied during the next reboot — the new service will be started automatically.