FreeBSD uses the rc(8) system of startup scripts during
system initialization and for managing services. The scripts
/etc/rc.d provide basic services
which can be controlled with the
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
natd_enable="NO" line is already
present, change the
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
restart options will only perform their action
if the appropriate
is set. For instance,
sshd restart will
only work if
sshd_enable is set to
restart a service regardless of the settings
/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
service sshd onerestart
service sshd rcvar# sshd # sshd_enable="YES" # (default: "")
# sshd line is output from the
above command, not a
To determine whether or not a service is running, use
status. For instance, to verify that
sshd(8) is running:
service sshd statussshd 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(R) operating systems.
The principal location for system configuration
/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
The entries in
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
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
/etc/rc.conf apply to all
sshd_enable="YES" keyrate="fast" defaultrouter="10.1.1.254"
Whereas these entries in
/etc/rc.conf.local apply to this system
hostname="node1.example.org" ifconfig_fxp0="inet 10.1.1.1/8"
/etc/rc.conf to every
system using an application such as
Upgrading the system will not overwrite
/etc/rc.conf, so system configuration
information will not be lost.