FreeBSD uses the rc(8) system of startup scripts during
system initialization and for managing services. The scripts
listed in /etc/rc.d
provide basic services
which can be controlled with the start
,
stop
, and restart
options to
service(8). For instance, sshd(8) can be restarted
with the following command:
#
service sshd restart
This procedure can be used to start services on a running
system. Services will be started automatically at boot time
as specified in rc.conf(5). For example, to enable
natd(8) at system startup, add the following line to
/etc/rc.conf
:
natd_enable="YES"
If a natd_enable="NO"
line is already
present, change the NO
to
YES
. The rc(8) scripts will
automatically load any dependent services during the next boot,
as described below.
Since the rc(8) system is primarily intended to start
and stop services at system startup and shutdown time, the
start
, stop
and
restart
options will only perform their action
if the appropriate /etc/rc.conf
variable
is set. For instance, sshd restart
will
only work if sshd_enable
is set to
YES
in /etc/rc.conf
.
To start
, stop
or
restart
a service regardless of the settings
in /etc/rc.conf
, these commands should be
prefixed with “one”. For instance, to restart
sshd(8) regardless of the current
/etc/rc.conf
setting, execute the following
command:
#
service sshd onerestart
To check if a service is enabled in
/etc/rc.conf
, run the appropriate
rc(8) script with rcvar
. This example
checks to see if sshd(8) is enabled in
/etc/rc.conf
:
#
service sshd rcvar
# sshd # sshd_enable="YES" # (default: "")
The # sshd
line is output from the
above command, not a
root
console.
To determine whether or not a service is running, use
status
. For instance, to verify that
sshd(8) is running:
#
service sshd status
sshd is running as pid 433.
In some cases, it is also possible to
reload
a service. This attempts to send a
signal to an individual service, forcing the service to reload
its configuration files. In most cases, this means sending
the service a SIGHUP
signal. Support for
this feature is not included for every service.
The rc(8) system is used for network services and it
also contributes to most of the system initialization. For
instance, when the
/etc/rc.d/bgfsck
script is executed, it
prints out the following message:
Starting background file system checks in 60 seconds.
This script is used for background file system checks, which occur only during system initialization.
Many system services depend on other services to function properly. For example, yp(8) and other RPC-based services may fail to start until after the rpcbind(8) service has started. To resolve this issue, information about dependencies and other meta-data is included in the comments at the top of each startup script. The rcorder(8) program is used to parse these comments during system initialization to determine the order in which system services should be invoked to satisfy the dependencies.
The following key word must be included in all startup scripts as it is required by rc.subr(8) to “enable” the startup script:
PROVIDE
: Specifies the services this
file provides.
The following key words may be included at the top of each startup script. They are not strictly necessary, but are useful as hints to rcorder(8):
REQUIRE
: Lists services which are
required for this service. The script containing this key
word will run after the specified
services.
BEFORE
: Lists services which depend
on this service. The script containing this key word will
run before the specified
services.
By carefully setting these keywords for each startup script, an administrator has a fine-grained level of control of the startup order of the scripts, without the need for “runlevels” used by some UNIX® operating systems.
Additional information can be found in rc(8) and rc.subr(8). Refer to this article for instructions on how to create custom rc(8) scripts.
The principal location for system configuration
information is /etc/rc.conf
. This file
contains a wide range of configuration information and it is
read at system startup to configure the system. It provides
the configuration information for the
rc*
files.
The entries in /etc/rc.conf
override
the default settings in
/etc/defaults/rc.conf
. The file
containing the default settings should not be edited.
Instead, all system-specific changes should be made to
/etc/rc.conf
.
A number of strategies may be applied in clustered
applications to separate site-wide configuration from
system-specific configuration in order to reduce
administration overhead. The recommended approach is to place
system-specific configuration into
/etc/rc.conf.local
. For example, these
entries in /etc/rc.conf
apply to all
systems:
sshd_enable="YES" keyrate="fast" defaultrouter="10.1.1.254"
Whereas these entries in
/etc/rc.conf.local
apply to this system
only:
hostname="node1.example.org" ifconfig_fxp0="inet 10.1.1.1/8"
Distribute /etc/rc.conf
to every
system using an application such as
rsync or
puppet, while
/etc/rc.conf.local
remains
unique.
Upgrading the system will not overwrite
/etc/rc.conf
, so system configuration
information will not be lost.
Both /etc/rc.conf
and
/etc/rc.conf.local
are parsed by sh(1). This allows system operators to
create complex configuration scenarios. Refer to
rc.conf(5) for further information on this
topic.
All FreeBSD documents are available for download at http://ftp.FreeBSD.org/pub/FreeBSD/doc/
Questions that are not answered by the
documentation may be
sent to <[email protected]>.
Send questions about this document to <[email protected]>.