UNIX System Administration Handbook - Evi Nemeth [27]
;;
restart)
echo -n "Stopping sshd: sshd"
kill `cat /var/run/sshd.pid`
echo "."
echo -n "Starting sshd: sshd"
/usr/local/sbin/sshd
echo "."
;;
*)
echo "Usage: /etc/init.d/sshd start|stop|restart"
exit 1
;;
esac
Although the scripts in init.d can start and stop individual services, init needs additional information about which scripts to run (and with what arguments) to enter any given run level. Instead of looking directly at the init.d directory when it takes the system to a new run level, init looks at a directory called rclevel.d, where level is the run level to be entered (e.g., rc0.d, rc1.d, and so on)
These rclevel.d directories typically contain symbolic links that point back to the scripts in the init.d directory. The names of these symbolic links all start with S or K followed by a number and the name of the service that the script controls (e.g., S34named). When init transitions from a lower run level to a higher one, it runs all the scripts that start with S in ascending numerical order with the argument start. When init transitions from a higher run level to a lower one, it runs all the scripts that start with K (for “kill”) in descending numerical order with the argument stop. Depending on the system, init may look only at the rclevel.d directory appropriate for the new run level, or it may look at every rclevel.d directory between the current run level and the new run level.
To tell the system when to start a daemon, we need to make symbolic links into the appropriate directory. Most systems seem to start the majority of their networking daemons during run level 2. For example, to tell the system to start sshd during run level 2 and to stop the daemon nicely before shutting down, we could make the following pair of links:
# ln -s /etc/init.d/sshd /etc/rc2.d/S99sshd
# ln -s /etc/init.d/sshd /etc/rc0.d/K25sshd
The first line tells the system to run the /etc/init.d/sshd startup script as one of the last things to do when entering run level 2 and to run the script with the start argument. The second line tells the system to run /etc/init.d/sshd relatively early when shutting down the system and to run the script with the stop argument. Some systems treat shutdown and reboot differently, so we will have to put a symlink in the /etc/rc6.d/ directory as well, to make sure the daemon shuts down properly when the system is rebooted.
Solaris startup scripts
Solaris, HP-UX, and Red Hat all use SystemV-style startup scripts that are kept in an init.d directory. Under Solaris, both the init.d and rclevel.d directories are in /etc.
In the past, Solaris’s init.d scripts referred to configuration files that were scattered all over the system, forming a huge, indecipherable mess. In recent releases, Sun has fixed a lot of this confusion. The startup scripts are much improved and are now relatively self-contained.
Several config files can be found in the /etc/default directory, although there aren’t a huge number of options there to tweak. Other config files are still somewhat scattered. Table 2.3 lists several important ones.
Table 2.3 Solaris startup configuration files
HP-UX startup scripts
Under HP-UX, the actual startup scripts are kept in /sbin/init.d. The run-level directories are also in /sbin. Config files that change the behavior of the startup scripts generally live in /etc/rc.config.d. Their names correspond to the names of the startup scripts in /sbin/init.d. For example, the script
/sbin/init.d/SnmpMaster
gets its configuration information from
/etc/rc.config.d/SnmpMaster
and is actually invoked from init by way of the links
/sbin/rc2.d/S560SnmpMaster
/sbin/rc1.d/K440SnmpMaster
HP-UX saves the output of startup scripts in /etc/rc.log. If one of your startup scripts fails, check /etc/rc.log to see if it contains any relevant error messages or hints as to the source of the problem. This saving of startup script output is a most useful and excellent feature, and it’s simple to implement, too. It’s surprising that other vendors haven’t caught on