Learn FreeBSD - System Services & the rc System

#Introduction

In the previous episode 5, you managed users and groups with pw and understood privilege escalation. Now we enter the heart of system automation: how services are started, stopped, and enabled automatically at boot.

FreeBSD uses a SysV-style rc system that is simple and predictable. Configuration is centralized in /etc/rc.conf, service scripts live in rc.d directories, and runtime control is handled by the service command. Combined with sysrc, you can manage all of it from the CLI without touching an editor. Let's dissect it layer by layer.

#The rc System: Core Concepts

#/etc/rc.conf: The Center of Configuration

All decisions about "which services are active" and "how they're configured" live in /etc/rc.conf. This is the only file you need to enable a service:

Contoh isi /etc/rc.conf

hostname="server01"
sshd_enable="YES"
ntpd_enable="YES"
ifconfig_em0="DHCP"

The pattern to watch for: service_enable="YES". The variable starts with the service name and ends with _enable. When bsdinstall creates your system, this file already contains the basic configuration.

#/etc/defaults/rc.conf: Default Values

FreeBSD stores the default values of all variables in /etc/defaults/rc.conf. Never edit this file — its values are overwritten on upgrade. Just read it to understand the available variables, then override them in /etc/rc.conf:

Membaca nilai default

grep -E "sshd|ntpd" /etc/defaults/rc.conf

The simple rule is: edit /etc/rc.conf, never touch /etc/defaults/rc.conf.

Warning

A common mistake for Linux users moving to FreeBSD is looking for service configuration in each service's own files, like sshd_config, to set "enable". On FreeBSD, application config files and enable settings are two separate things: enabling goes in rc.conf, application parameters go in the application's own config file.

#rc Scripts in the rc.d Directories

Scripts that control services live in two locations:

/etc/rc.d/ — services that are part of the base system (sshd, ntpdate, routing).
/usr/local/etc/rc.d/ — services from pkg and ports (nginx, mysql, doas).

Each script supports standard actions: start, stop, restart, status, reload, and rcvar. Read a script to understand the variables it supports:

Melihat variabel yang didukung skrip

service sshd rcvar

The output shows the sshd_enable="YES" line and sshd_flags — exactly what you need to put in rc.conf.

#The service Command

#Runtime Control

Once a service is enabled, manage its runtime state with service:

Mengelola service sshd

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

service <name> onestart is useful for running a service that isn't enabled in rc.conf — it runs once without making it persistent at boot:

Menjalankan service sekali tanpa enable

service nginx onestart

#Running Your Own Scripts

You can also place custom scripts in /usr/local/etc/rc.d to have them managed the same way. I'll cover this pattern further in episode 11 when we build a custom service.

#The Boot Order: Loader, Kernel, and rc

Understanding the boot order helps you troubleshoot services that don't appear at start:

The firmware (UEFI/BIOS) loads the bootloader.
The bootloader reads /boot/loader.conf and loads the kernel.
The kernel initializes hardware, then calls init and /etc/rc.
/etc/rc reads /etc/defaults/rc.conf + /etc/rc.conf, then runs the rc scripts in order.

The boot process log is stored in /var/log/boot.log (if enabled) and can be inspected with dmesg. If a service fails to start, note its order here.

#/etc/rc.local

For one-shot commands at the end of boot, FreeBSD supports /etc/rc.local. This file is executed last, after all services:

Contoh /etc/rc.local

echo "Boot selesai" > /var/log/rc.local.log

Info

Use /etc/rc.local wisely. For work that must be restartable or controllable, it's better to write a proper rc script than to hide everything in an rc.local that's hard to audit.

#sysrc: Managing rc.conf from the CLI

sysrc is the tool that makes managing rc.conf without an editor possible. Its syntax resembles changing shell variables:

Mengaktifkan service dengan sysrc

sysrc sshd_enable="YES"
sysrc nginx_enable="YES"
sysrc nginx_flags="-c /usr/local/etc/nginx/nginx.conf"

sysrc reads and writes /etc/rc.conf, creates a backup before changes, and preserves the file format. Check existing values:

Melihat nilai variabel

sysrc sshd_enable
sysrc -a

sysrc -a displays the entire contents of rc.conf. This is a quick way to audit what's active on the system. Because it edits files programmatically, sysrc is perfect for provisioning scripts and automation playbooks.

Success

The combination of sysrc for setting config and service for controlling runtime is a pair of keywords you'll use every day on FreeBSD. Both are idempotent and easy to learn — great for automation and executable documentation.

#Practical Workflow: Enabling a Service

Let's practice the complete pattern for enabling nginx from pkg:

Pola lengkap aktivasi service

pkg install nginx
sysrc nginx_enable="YES"
service nginx start
service nginx status

These four lines are the pattern you'll repeat for nearly every service: install, enable, start, verify. Remember, sysrc replaces the need to open an editor for enable settings.

#Closing

In this episode 6, you understood the FreeBSD rc system: /etc/rc.conf as the center of configuration, /etc/defaults/rc.conf as default values that must not be edited, rc scripts in two directories, the service command for runtime control, the boot order, and sysrc as a CLI-based configuration manager.

Key takeaways:

Service enablement is written in /etc/rc.conf with the pattern service_enable="YES".
Never edit /etc/defaults/rc.conf — it holds defaults that are overwritten on upgrade.
service <name> start/stop/restart/status controls the runtime.
Boot order: loader, kernel, /etc/rc, then rc scripts.
sysrc changes rc.conf without an editor and is safe for automation.

In the next episode, episode 7, we'll cover filesystems, mounts & disks — from UFS and ZFS, pseudo-filesystems like tmpfs and devfs, to mount and umount, /etc/fstab configuration, and swap management. This storage foundation determines how your data lives on disk.