next up previous contents
Next: Managing runlevels - Up: 2.3.1 System 5 init Previous: /etc/init.d/functions   Contents Other scripts

Other scripts that get called from /etc/rc.d if they exist:

/etc/rc.d/rc.serial (may be needed to setup non-standard serial ports)

/etc/rc.d/rc.modules (comments say: "for backward compatibility with VARs") - if you ever find yourself tempted to edit this file, consider putting your additions in another script /etc/rc.local.

/etc/rc.d/rc 3 - /etc/rc.d/rc is the script and "3" is a command-line argument telling it to process the runlevel-3 subdirectory (/etc/rc.d/rc3.d). It's responsible for starting and stopping services when the runlevel changes. Runs all "kill-scripts", and then all "start-scripts". Before running anything, it reads ("sources") /etc/rc.d/init.d/functions.

(N=0,1,..,6) - the elegance revealed
All files in any rcN.d subdirectory are symbolic links, and with one exception, they all link to scripts in /etc/rc.d/init.d - for example S40crond links to /etc/rc.d/init.d/crond. The exception is the start script S99local (in runlevels 2-5 only), which is a link to /etc/rc.d/rc.local.

The default rc.local script, BTW doesn't do very much of great complexity; it only creates the file /var/lock/subsys/local on startup. It's only other remaining purpose is as a location for custom initializations for which the system administrator doesn't wish to create a complete startup script in /etc/init.d/ and that is desired in all (normal) runlevels.

from "ud::once:/sbin/update" - after the runlevel-specific configuration step above, the "any-runlevel" line from inittab gets run.

/sbin/mingetty tty1 (and similar "respawn" action lines) - the getty programs are started after everything else.

That's it! After the terminal gettys are started, you can login on any virtual console, or accept connections if any gettys were created on serial ports.

More about /etc/rc.d/init.d scripts
Typically the scripts in /etc/init.d follow a standard format, and commonly either start or kill a daemon. But they *could* do anything. The nfsfs script, for example mounts or unmounts all nfs filesystems that are defined in /etc/fstab. These scripts are generally easy to read and figure out. Most of them examine their command line input and do the appropriate thing corresponding to arguments of "start", "stop", "restart", "status". Sometimes there is a "reload" argument which may be either a synonym for restart, or perhaps a more efficient re-initialization. So, now you know a configuration trick: if you change some configuration data file associated with (say) sendmail, you can ensure the changes are honored by executing the command '/etc/rc.d/init.d/sendmail restart' - don't forget the argument, "restart". Be aware that script names often duplicate the name of a binary executable somewhere in your path, so DON'T try to execute (for example) 'sendmail restart', this will not work!.

next up previous contents
Next: Managing runlevels - Up: 2.3.1 System 5 init Previous: /etc/init.d/functions   Contents