Next: 2.3.1.5 Managing runlevels -
Up: 2.3.1 System 5 init
Previous: 2.3.1.3 /etc/init.d/functions
Contents
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.
- rc
-
/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.
- rcN.d
- (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.
- update
-
from "ud::once:/sbin/update" - after the runlevel-specific
configuration step above, the "any-runlevel" line
from inittab gets run.
- gettys
-
/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: 2.3.1.5 Managing runlevels -
Up: 2.3.1 System 5 init
Previous: 2.3.1.3 /etc/init.d/functions
Contents
