Learn DragonFlyBSD - System Services & rc System

#Introduction

In episode 5 you managed identities: users, groups, and privileges. But what's the point of all that if nothing is running? This episode answers the question administrators face most often: how does the system know which services to run at boot? The answer lies in the rc system — a Unix legacy that BSD adapted very neatly.

Think of the rc system as an airport with a detailed flight schedule. There's an official timetable (/etc/rc.conf), standard procedures (/etc/defaults/rc.conf), crews carrying out tasks (/etc/rc.d/), and air traffic controllers ensuring planes take off in the right order (rcorder). You're about to become that air traffic controller.

#Anatomy of the rc System

#/etc/defaults/rc.conf: The Official Schedule

/etc/defaults/rc.conf is the document containing the default values for all boot configuration variables. It's populated by the system and — importantly — must never be edited directly. Any change will be overwritten when the base system is updated. Its job is to serve as a reference: from this file the system knows which defaults to use when no override exists.

Open this file to learn:

less /etc/defaults/rc.conf

There you'll find variables like rc_conf_files, hostname, ifconfig_default, and the list of default services.

#/etc/rc.conf: The Active Configuration File

/etc/rc.conf is where you write overrides. The system reads the defaults and then applies whatever is here on top. This is the file you'll edit throughout your administrative career. Here's a realistic example:

hostname="server-01.internal"
ifconfig_em0="DHCP"
sshd_enable="YES"
ntpd_enable="YES"

#/etc/rc.conf.local: Local Configuration

When you manage many servers with shared configuration (for example via centralized configuration), /etc/rc.conf may be filled by a management tool — and per-machine local overrides are better kept separate. That's where /etc/rc.conf.local comes in: this file is read after rc.conf and acts as the final layer. This habit keeps machine-specific changes from being overwritten when shared configuration is re-rendered.

#/etc/rc.d/: Service Scripts

Every service has a script in /etc/rc.d/. These scripts understand standard verbs like start, stop, restart, status, and rcvar. When you set sshd_enable="YES", the rc system knows which script to run at boot — sshd — thanks to the naming convention. Look at the list:

ls /etc/rc.d/

#rcorder: The Boot Order Controller

Not every service can start in any order. Services that need the network must wait for the network to be ready; services that depend on a database must wait for the database. rcorder solves this by reading dependency declarations from each script:

rcorder /etc/rc.d/* | head -20

Each script declares REQUIRE, PROVIDE, and BEFORE — and rcorder produces a valid total order from those declarations. This is why booting runs smoothly without complicated manual configuration.

#Managing Services

#The service Command

The easiest way to control a service is the service command:

service sshd status
service sshd start
service sshd restart
service sshd stop

service is a wrapper that calls the script in /etc/rc.d/ with the appropriate verb. All the standard verbs are available: start, stop, restart, status, rcvar, and enable/disable on recent versions.

#Enabling Services at Boot

Running a service once doesn't mean it boots with the system. To enable it permanently, add the _enable variable in rc.conf:

echo 'sshd_enable="YES"' >> /etc/rc.conf.local
echo 'ntpd_enable="YES"' >> /etc/rc.conf.local

After that, the rc system will run the service automatically at every boot. To check which variables apply to a service, use service <name> rcvar:

service sshd rcvar

#Disabling Services

To disable a service at boot, set its variable to "NO":

echo 'dhcpd_enable="NO"' >> /etc/rc.conf.local

A disabled service won't boot with the system, but an already-running process will stay alive until stopped manually. To stop a running service and prevent it from coming back at boot, do both.

#Closing

In this episode 6 you understood the DragonFlyBSD rc system thoroughly: the role of /etc/rc.conf as the active configuration, /etc/defaults/rc.conf as the source of defaults, /etc/rc.d/ as the collection of service scripts, the service command for control, and rcorder, which builds the boot order from dependencies. You also learned to enable and disable services via /etc/rc.conf.local.

Key takeaways:

• Edit /etc/rc.conf (and /etc/rc.conf.local) for overrides; don't touch /etc/defaults/rc.conf.
• service sshd restart controls a service; service <name> rcvar shows the variables affecting it.
• Set sshd_enable="YES" to make a service automatic at boot.
• rcorder builds the boot order from each script's REQUIRE/PROVIDE declarations.
• Keep local overrides in /etc/rc.conf.local so they're safe when shared configuration is re-rendered.

In the next episode, episode 7, we'll dive into filesystems, mounts & disks: the differences between HAMMER2, UFS, tmpfs, and mfs, how mount/umount work, disk management with disklabel and newfs_hammer2, laying out /etc/fstab, checking with fsck, and swap configuration.