Booting FreeBSD

A 10.000ft overview:

The kernel starts init as PID 1
init runs a script or interactive shell
init spawns getty and acts as default reaper

Booting FreeBSD with /etc/rc

A 1.000ft view:

The kernel starts /sbin/init
init acts according to its arguments passed by the bootloader through the kernel
init starts /etc/rc or the single user shell
/etc/rc orders the rc.d scripts with rcorder
the early rc.d scripts are run serially as ordered
the late rc.d scripts are run serially as ordered

Design choices made

Serial execution → Booting is slow
Lots of parsing → Booting is slow
Everything is dynamic → Very flexible, little validation
Supervision limited to /etc/ttys entries → Only getty is supervised

Definitions

To continue our discussion we need a few definitions.

Init Process
Process Supervision
Service
Service Management

Definition: Init Process

The process running with PID 1. If it exits for any reason the kernel panics.

Definition: Process Supervision

Supervised Process: A process spawned as part of the supervision tree
Scanner (s6-svscan): Scans for services, Starts one supervisor per service directory
Supervisor (s6-supervise): Supervises a single long running process (and its logger)
Root: A scanner with no parent
Supervision Tree: Set of supervised processes

Definition: Service

Oneshot: short lived script run for its side-effect
Longrun: a long running process offering some service
Bundle: a set of other services

Services can have hard forward dependencies.

Definition: Service Management

Startup: Start all enabled services
Shutdown: Stop all running services
Runtime: Change system state upon request== The s6-rc design

Finding the init executable

The kernel searches the init_path kenv for potential locations of init It defaults to /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init. Changing init_path from the loader prompt is enough to switch back and forth.

Constrains on PID 1

PID 1 must not die
- The kernel panics if PID 1 dies
- exec(2) is allowed
PID 1 with just a read only root filesystems
- /usr/ may be on a different filesystem
- Can’t write state to the filesystem
- Can’t bind unix sockets

Working around the constrains of PID 1

Spawn a FreeBSD specific script as PID 1
Use the script to:
- Mount a tmpfs
- Copy the early services (a getty and a default logger)
- exec into s6-svscan

s6-svscan

Watches the scan dir a directory of (symlinks to) service dirs
Preallocates logging pipes
Starts one s6-supervise per service dir

s6-supervise

Supervises a single long running process and its logger
./run script: Becomes the service
./finish script: Clean up after the service
./env/ dir: Contains one file per environment variable
./notification-fd file: Used for readiness notification
./event/ dir: Each watching process puts a pipe here
./supervise/ dir: Contains the control fifo and service state
./log/ dir: Not used by s6-rc

s6-rc-compile:

s6-rc-compile compiled source...

Compile source directorys into a single compiled directory in compiled format
./type: Either bundle, longrun or oneshot

Atomics (longrun, oneshot):

Timeouts for state transitions
./dependencies: A list of forward dependencies, loops are prohibited

Oneshots:

./up: Perform the state transition
./down: Reverse the state transition
Could just wrap each existing rc.d script

Pipelining

Longruns can be connected by pipes
Each consumer must have n ≥ 1 producers

Logging

There is nothing preventing you from keeping syslogd
s6-rc has a better alternative
- Use a logging pipe as stdout and stderr
- Log into a dedicated logging process
- Or use the inherited pipe to the default logger

Preparing the system for s6-rc

s6-rc-init -p default. /run/service

Creates symlinks and lockfiles
s6-rc-init has to be called to initialize the s6-rc service manager
Multiple instances can share a scan dir

Atomic service database updates

Emulate atomic updates to directories with symlinks
s6-rc-init uses /etc/s6-rc/compiled by default
Compile to /etc/s6-rc/.compiled-$UUID and update symlink

Switching the service database at runtime

s6-rc-update [ -f convfile ] newdb

Adds/removes services
Services can be renamed e.g. hostid → hostuuid
Restarts can be forced e.g. mysql → mariadb restart
Old service databases should be garbage collected

Booting FreeBSD with s6-rc

# Prepare a writable file system
echo "tmpfs /run tmpfs rw,mode=0755,size=${RUN_SIZE} 0 0" |
        env PATH_FSTAB=/dev/stdin mount -a
s6-hiercopy /etc/run /run

# As soon as loging is available
s6-rc-init -p default. /run/service
s6-rc change "enabled"

# Become the true init process
exec s6-svscan -s /run/service

Network configuration

Static network interfaces and static routes treated bundles of oneshot services
Dynamic network interfaces can be treated as bundles of longrun services
Reacting to changes with devd
A proper network manager would be nice to have

Supervising login sessions

s6-svscan doesn’t require special privileges
Can be used to supervise the WM and screensaver

Live demo

mount-rw
devd
OpenSSH

Thanks

I would like to thank Laurent Bercot for writing s6-rc and testing it more than one platform.

Conclusion

Switching init on FreeBSD is possible with minimal breakage
Getting the most out of s6-rc requires more than a simple port
Without some default policies s6-rc is cumbersome to use

Porting s6 to FreeBSD as PID 1