Learn NetBSD - System Services & the rc System

#Introduction

In episode 5 we set up users and groups, and limited root access. Now imagine a system that's powered off — how does it come back to life? On every boot, NetBSD runs a sequence of services in the right order. In this episode we'll dissect the NetBSD rc system: how /etc/rc.conf controls everything, how the scripts in /etc/rc.d work, and how rcorder decides who goes first.

This is one of the most obvious differences from modern Linux. Linux uses systemd; NetBSD sticks with the simple, transparent, scriptable BSD rc philosophy. There are no mysterious unit files — everything is a shell script you can read line by line. Let's open up the machinery.

#rc System Architecture

NetBSD's rc system consists of several complementary layers:

Component	Function
`/etc/rc.conf`	Main service configuration (what you edit)
`/etc/defaults/rc.conf`	Default values for all parameters (don't edit)
`/etc/rc.d/`	Individual service scripts
`/etc/rc`	Entry point that runs all scripts at boot
`rcorder`	Tool that determines script execution order
`service`	Front-end for running rc scripts

The principle: never edit /etc/defaults/rc.conf. You copy the parameters you want to change into /etc/rc.conf or /etc/rc.conf.local, and those values override the defaults.

#/etc/rc.conf: The Control Center

Every NetBSD installation produces an /etc/rc.conf containing the basic configuration. Let's look at its contents:

Reading rc.conf

cat /etc/rc.conf

Example rc.conf contents after installation

rc_configured=YES
hostname="nbsd11"
ifconfig_wm0="DHCP"
sshd=YES

Notice the pattern: each service is represented by one variable, and the value YES means enabled. This setting is proof from episode 3 — the network config we chose in sysinst is stored here (ifconfig_wm0="DHCP").

For per-machine configuration without touching the main file, NetBSD provides /etc/rc.conf.local. This is useful when /etc/rc.conf is managed by provisioning tools — local additions just go in the .local file:

Contents of /etc/rc.conf.local

postfix=YES
httpd=NO

#Scripts in /etc/rc.d

Every service has a script in /etc/rc.d/. Let's see what's available and how to read a script:

Listing service scripts

ls /etc/rc.d

Partial example output

accounting  dhcpcd  fsck  named  network  ntpdate  sshd  syslogd  wscons ...

A script follows the same convention: variable definitions like name, command, rcvar, followed by an include of the common file. Here's the essence of /etc/rc.d/sshd:

Contents of /etc/rc.d/sshd (abridged)

name="sshd"
command="/usr/sbin/sshd"
rcvar=${name}
command_args="-D"
run_rc_command "$1"

This script is "standard" — NetBSD provides a framework (rc.subr) that handles start/stop/status/restart uniformly. This is why all NetBSD services behave consistently.

#Running Services with `service`

NetBSD doesn't have rcctl like OpenBSD. Its tool is the service command:

Running a service manually

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

Example service sshd status output

sshd is running as pid 1234.

Whenever you're unsure about a command, service also provides help:

Viewing all actions a script supports

service sshd help

#rcorder: Determining the Order

How does NetBSD know that the filesystem must be mounted before the network is started? The answer is rcorder — a tool that reads the dependency declarations inside each script and orders them.

Inside each script there are declaration comments like these:

Dependency declarations in an rc script

# REQUIRE: mountcritlocal network
# PROVIDE: sshd
# BEFORE:  firewall

Three important keywords:

Keyword	Meaning
`PROVIDE`	What service this script provides
`REQUIRE`	What services must run before this one
`BEFORE`	What services must run after this one

At boot, /etc/rc runs rcorder /etc/rc.d/* over all scripts to produce the optimal order:

Viewing the boot order produced by rcorder

rcorder /etc/rc.d/*

Partial example output (boot order)

/etc/rc.d/mountcritlocal
/etc/rc.d/sysctl
/etc/rc.d/fsck
/etc/rc.d/mountall
/etc/rc.d/network
...
/etc/rc.d/sshd
/etc/rc.d/postfix

Notice: mountall before network, and network before sshd. Dependencies are resolved automatically without hardcoded ordering.

#Adding Your Own Service

You can write your own rc script for any service. Save it as /etc/rc.d/service-name using the standard pattern:

Example simple rc script for a custom daemon

#!/bin/sh
name="mydaemon"
command="/usr/local/sbin/mydaemon"
command_args="-f /etc/mydaemon.conf"
rcvar=${name}
run_rc_command "$1"

Make it executable, then enable it in /etc/rc.conf.local:

Enabling a custom service

chmod +x /etc/rc.d/mydaemon
echo 'mydaemon=YES' >> /etc/rc.conf.local

Warning

Every time you change an rcvar value to YES, the service won't run until it's explicitly started or the system is rebooted. Use service name restart to apply the change without rebooting.

#Closing

In this episode 6, you've mastered the NetBSD rc system: understanding /etc/rc.conf as the control center, /etc/defaults/rc.conf as the source of default values, the scripts in /etc/rc.d, the service command, and rcorder's role in determining the boot order. You can also write your own service scripts.

Key takeaways:

Never edit /etc/defaults/rc.conf — override its values in /etc/rc.conf or /etc/rc.conf.local.
Enable a service with service_name=YES, then service name start.
There's no rcctl on NetBSD — use the service command.
rcorder resolves the boot order based on PROVIDE/REQUIRE/BEFORE.
rc scripts are shell scripts — transparent, easy to read, easy to write yourself.

In the next episode, episode 7, we'll move from the living to the storing: filesystems, mounts, and disks — understanding FFS, mounting tmpfs and cd9660, managing disklabel and newfs, and keeping disks healthy with fsck and swapctl. See you in episode 7!