Table of Contents
As of NetBSD 1.5, the startup of the system changed to using rc-scripts for controlling services, similar to the init-system System V and Linux use, but without runlevels. This chapter is an overview of the rc-system and its configuration on NetBSD.
The startup files for the system reside under
/etc
, they are:
/etc/rc
/etc/rc.conf
/etc/rc.d/*
/etc/rc.lkm
/etc/rc.local
/etc/rc.shutdown
/etc/rc.subr
/etc/defaults/*
/etc/rc.conf.d/*
First, a look at controlling and supporting scripts, also documented in rc(8):
When the kernel has initialized all devices on
startup, it usually starts init(8), which in turn runs
/etc/rc.d
/etc/rc
sorts the scripts in
/etc/rc.d
using rcorder(8), and
runs them in that order. See the rcorder(8)
manpage for more details on how the order of
/etc/rc.d
scripts is determined.
/etc/rc.subr
contains common functions used by many
/etc/rc.d/*
scripts.
When shutting down the system with shutdown(8),
/etc/rc.shutdown
is run which runs the
scripts in /etc/rc.d
in reverse
order (as defined by rcorder(8)).
Additional scripts outside of the rc.d
directory:
/etc/rc.lkm
loads or unloads
Loadable Kernel Modules (LKMs), see modload(8) and
/etc/rc.d/lkm[123]
.
/etc/rc.local
is almost the last
script called at boot up. This script can be edited by the
administrator to start local daemons that don't follow the
rc-concept.
For example, packages installed pkgsrc usually add their
startup files to /usr/pkg/etc/rc.d
, and
it's left as a decision to the system administrator on
enabling them, either by manually copying/linking them to
/etc/rc.d
, or by adding them to
/etc/rc.local
. The following is the
example from the system for an apache web server added to
/etc/rc.local
:
if [ -f /usr/pkg/etc/rc.d/apache ]; then /usr/pkg/etc/rc.d/apache start fi
There's a central config file for bootscripts, rc.conf(5)
located in
/etc/rc.conf
.
/etc/rc.conf
loads its defaults from
/etc/defaults/rc.conf
, the latter of which
should not be touched. In order to alter a default setting,
an override may be installed in
/etc/rc.conf
.
For example, if you wanted to enable the Secure Shell Daemon:
#
cd /etc; grep ssh defaults/rc.conf
sshd=NO sshd_flags=""#
echo "sshd=YES" >> rc.conf
Or just edit /etc/rc.conf
with your
favorite editor. The same can be done with any default that
needs to be changed. A common sequence often done after
installing a fresh NetBSD system is:
#
cat /etc/defaults/rc.conf >>/etc/rc.conf
#
vi /etc/rc.conf
Be careful to use “>>” and not
“>” else you will destroy the default contents
in /etc/rc.conf
, which are critical to
remain there! After you have copied the defaults that way,
modify anything you need to in
/etc/rc.conf
. Be sure to consult the
rc.conf(5) manpage to explain all the settings in
detail.
Last and not least, the /etc/rc.conf.d/
directory can be used for scripts-snippets from third party
software, allowing setting only one or few settings per file.
The actual scripts that control services are in
/etc/rc.d
. Once a service has been activated
or told not to activate in /etc/rc.conf
it
can be also be modified by calling the rc script from the command
line, for example if an administrator needed to start the secure
shell daemon:
#
/etc/rc.d/sshd start
Starting sshd.
The rc scripts must receive one of the following arguments:
start
stop
restart
kill
An example might be when a new record has been added to the named database on a named server:
#
/etc/rc.d/named restart
Stopping named. Starting named.
A slightly more complex example is when a series of settings have been changed, for instance a firewall's ipfilter rules, ipnat configuration, and the secure shell server has switched encryption type:
#
sh /etc/rc.d/ipfilter restart
#
sh /etc/rc.d/ipnat restart
#
sh /etc/rc.d/sshd restart
The startup system of every Unix system basically determines
the order in which services are started one way or another. On
some Unix systems this is done by numbering the files and/or
putting them in separate run level directories. (Solaris relies
on wildcards like /etc/rc[23].d/S*
being
sorted numerically when expanded.) Or they simply put all the
commands that should be started at system boot time into a
single monolithic script, which can be messy. (This is what ancient
BSD and NetBSD did before the rc-system). On NetBSD this is done
by the rc-scripts and their contents. Please note that NetBSD does
not have multiple runlevels as found e.g. in System V systems
like Solaris, or Linux.
At the beginning of each of the rc-scripts in
/etc/rc.d/*
, there is a series of
comment-lines that have one of the following items in them:
REQUIRE
PROVIDE
BEFORE
KEYWORD
These dictate the dependencies of that particular rc script and
hence rcorder can easily work either “up” or
“down” as the situation requires. Following is
an example of the /etc/rc.d/nfsd
script:
... PROVIDE: nfsd REQUIRE: mountd . /etc/rc.subr ...
Here we can see that this script provides the “nfsd” service, however, it requires “mountd” to be running first. The rcorder(8) utility will be used at system startup time to read through all the rc-scripts, and determine the correct order in which to run the rc-scripts (hence its name).
There are other resources available pertaining to the rc.d system:
One of the principal designers of rc.d, Luke Mewburn, gave a presentation on the system at USENIX 2001. It is available in PDF format.
Will Andrews wrote a Daemonnews article called The NetBSD rc.d System.