-These scripts are intended to handle both boot time and
-run-time management of system services and general configuration.
-
-In general, the philosophy is to be as simple as possible. The
-admin who has to debug a boottime or service start up script
-that he hasn't looked at in a year and a half and that was set
-up by his predecessor anyway doesn't want something that can't
-be understood with a basic knowledge of init, the shell, and
-a couple of man pages.
-
-A system administrators accumulated knowledge should also be
-respected as far as possible. There is no point in throwing
-away years of experience merely for the sake of being different.
-Further, the system should follow, as much as possible the
-principle of least surprise.
-
-Where possible, configuration scripts should be simple /bin/sh
-compatible files that do nothing other than set variables
-and do not call any programs. This allows other scripts
-to simply source them without any complicated parsing.
-
-However, where existing tools use configuration files that don't adhere
-to that principle, those files and tools should continue to be used
-unchanged. As examples, /etc/fstab, /etc/sysctl.conf.
+These scripts are intended to handle both boot time and run-time management of
+system services and general configuration.
+
+In general, the philosophy is to be as simple as possible. The admin who has
+to debug a boottime or service start up script that he hasn't looked at in a
+year and a half and that was set up by his predecessor anyway doesn't want
+something that can't be understood with a basic knowledge of init, the shell,
+and a couple of man pages.
+
+A system administrators accumulated knowledge should also be respected as far
+as possible. There is no point in throwing away years of experience merely for
+the sake of being different. Further, the system should follow, as much as
+possible the principle of least surprise.
+
+Where possible, configuration scripts should be simple /bin/sh compatible files
+that do nothing other than set variables and do not call any programs. This
+allows other scripts to simply source them without any complicated parsing.
+
+However, where existing tools use configuration files that don't adhere to that
+principle, those files and tools should continue to be used unchanged. As
+examples, /etc/fstab, /etc/sysctl.conf.
In keeping with the above, these scripts work as follows:
Run Level S: single user mode
Run Level 1: also single user mode
-Run Level 2: multi user mode, but with as little running as
-might be needed for maintaining the box. Typically this
-will be networking and sshd, but nothing else. For some
-systems even these may not be needed.
+Run Level 2: multi user mode, but with as little running as might be needed for
+maintaining the box. Typically this will be networking and sshd, but nothing
+else. For some systems even these may not be needed.
Run Level 3: This is the normal "everything running" level.
Run Level 6: System shutdown
-No other run levels are used, though a system admin could
-set them up if needed.
+No other run levels are used, though a system admin could set them up if
+needed.
System Scripts
--------------
These scripts live in /etc
-fstab: lists filesystems, this file is not changed from it's usual
-format, and is used as such
+fstab: lists filesystems, this file is not changed from it's usual format, and
+is used as such
-rc.sysinit: done once at start time. responsible for performing any
-necessary early system initialization. This reads rc.conf for some
-of its actions
+rc.sysinit: done once at start time. responsible for performing any necessary
+early system initialization. This reads rc.conf for some of its actions
* do any boot time /tmp cleanup or similar
* fsck and mount filesystems
* configure the console
* set timezone and clock
-Since all of this has to be done before we do anything else,
-and the order won't generally change, this can and should be
-a single script.
+Since all of this has to be done before we do anything else, and the order
+won't generally change, this can and should be a single script.
rc.multi: brings up the system into multi user mode. reads rc.conf
rc.conf:
-responsible for setting variables used by other scripts. this script will
-be sourced by several other scripts and thus shouldn't actually perform
-any actions of its own. It can call other programs if needed to set variables,
-but this should be minimized (e.g. it could cat /etc/hostname to set the HOSTNAME
-variable, but shouldn't actually set the hostname, and it would be better to just
-set the hostname directly)
+responsible for setting variables used by other scripts. this script will be
+sourced by several other scripts and thus shouldn't actually perform any
+actions of its own. It can call other programs if needed to set variables, but
+this should be minimized (e.g. it could cat /etc/hostname to set the HOSTNAME
+variable, but shouldn't actually set the hostname, and it would be better to
+just set the hostname directly)
DAEMONS: a set of scripts from /etc/rc.d/init.d to run. These will
be run in the order listed.
Robustness
----------
-Each daemon start-up script should register somehow the fact that it
-is running and started. A monitoring daemon then should be run *out of init*
-to check these daemons and restart them if they crash. If the monitor
-is not run from init, it could itself crash. This should perhaps be
-run level 4 for this daemon. Ideally, nothing would be run as a daemon
-and init could handle the monitoring itself, but this would be a major
-change to the usual practice.
+Each daemon start-up script should register somehow the fact that it is running
+and started. A monitoring daemon then should be run *out of init* to check
+these daemons and restart them if they crash. If the monitor is not run from
+init, it could itself crash. This should perhaps be run level 4 for this
+daemon. Ideally, nothing would be run as a daemon and init could handle the
+monitoring itself, but this would be a major change to the usual practice.