init

situation: responsible for early system setup, services, and shutdown.

overview

dérive uses a single init program called situation. situation is a minimal POSIX sh script located at /bin/situation and runs as PID 1.

design

situation executes entirely in userspace and assumes a Linux kernel with VFS enabled.

responsibilities: - mounting essential filesystems - creating minimal device nodes - early system configuration - starting services - spawning login consoles - handling shutdown and poweroff

what it doesn't do: - service supervision - dependency resolutions - parallel orchestration other than shell backgrounding - abstraction layers

the script is readable from top-to-bottom and executes sequentially. there is no event model and no persistent daemon other than PID 1 itself.

boot sequence

situation performs the following steps, in order:

1. mount /proc and /sys
2. mount (or create) /dev
3. create essential devices if devtmpfs is unavailable
4. create and attempt to mount:

• /dev/pts
• /dev/shm
• /run
• /tmp

1. create /var/run and /var/log
2. ensure utmp and wtmp exist
3. remount the root filesystem with read-write
4. set the system hostname from /etc/hostname
5. disable kernel module auto-loading
6. reduce kernel logging verbosity
7. initialise device manager and trigger a one-time device population
8. bring up the loopback interface if ip utility is available
9. run /etc/rc.local if present (may be executed more than once)
10. start enabled services
11. spawn login consoles
12. enter an idle loop until shutdown

if any critical step fails, the system drops to an emergency shell.

configuration

hostname

if /etc/hostname exists, the hostname will be the contents. if it's missing, the hostname defaults to linux.

device management

if available, smdev is preferred over mdev. only one device manager is used. the kernel hotplug handler is set explicitly if supported. no udev-compatible tooling is supported.

kernel behaviour

situation disables automatic kernel module loading by writing /bin/sh to:

/proc/sys/kernel/modprobe

kernel logging verbosity is also reduced early during boot.

ICMP permissions

if supported by the kernel, unprivileged ICMP sockets are enabled via:

/proc/sys/net/ipv4/ping_group_range

This allows ping to function without setuid binaries or capabilities.

privilege fixups

some binaries (e.g. doas) may have their ownership and permissions restored during boot. this is required because the kernel does not preserve setuid bits from the initramfs.

services

services are enabled by placing executable shell script in:

/etc/sv/on/

while you can put a non-shellscript/executable, you will probably have a bad time!

each file is started in sorted order. services: - are started in the background - are not supervised - are not restarted on failure - have the PIDs of initial processes recorded in /etc/sv/pid/

If a service fails to start, the system continues booting.

consoles

if getty is available, situation spawns: - a serial console on ttyS0 - a VGA console on tty1

each console is respawned in a small loop if it exits. if getty is unavailable, it falls back to an interactive shell on the console.

shutdown

situation handles shutdown when it receives SIGINT or SIGTERM.

shutdown happens like so:

1. send SIGTERM to all recorded service PIDs
2. send SIGTERM to remaining processes using killall5
3. attempt to unmount all mounted filesystems
4. sync disks
5. poweroff

failure modes

• failure to mount /proc or /sys drops the system to an emergency shell
• missing or unexecutable service files are skipped
• failed service startup does not halt boot
• missing getty results in a console shell instead of a login prompt
• /etc/rc.local may be executed more than once during boot

if PID 1 exits, the system will panic!