Where 66 stands among init systems - 66 documentation
Skip to content
Initializing search
Obarun/66
What 66 does not do
Portability
Placement
Running 66 inside a container
66 commands
Extra tools
Internal tools
Reference
What 66 does not do
Portability
Placement
Where 66 stands among init systems¶
An honest placement of 66 next to runit, the s6 stack, OpenRC, finit, dinit and systemd:<br>what it is alone in doing, what it deliberately does not do, and what the remaining gaps<br>would actually cost to close.
The grid that matters¶
Most init comparisons are shouting matches about size. Two axes are enough to place<br>everyone without arguing about taste.
Axis A, the supervision model. One supervisor process per service (PID 1 stays tiny,<br>supervision survives a crash of the manager) versus one monolithic manager that watches<br>every service itself.
Axis B, the richness of the service model. Raw shell scripts, versus a complete<br>declarative model, versus a full system layer that also owns login, network, DNS,<br>logging and an IPC bus.
Crossing them places everyone. Axis B runs down the rows, widest scope at the top and<br>poorest model at the bottom; axis A splits the columns.
Axis B ↓ / Axis A →<br>one supervisor per service<br>one monolithic manager
System platform : also owns login, network, DNS, logging, an IPC bus<br>empty<br>systemd
Complete declarative model : dependencies, instances, groups as objects, readiness, user scope<br>66<br>dinit · finit
Declarative, narrower : a dependency graph over a script-shaped model<br>s6 stack
Scripts : no native model<br>runit<br>OpenRC (no native supervision at all)
Two things fall out of it.
66 holds a cell nobody else occupies. Everything else in its column, runit and the s6<br>stack, has the supervision model but a much poorer service model. Everything else on its<br>row, dinit and finit, has a comparable service model but a manager that supervises every<br>service itself, so a bug in the manager takes the whole supervision tree down with it.<br>Nobody else has both.
The row above is a different job, not a higher grade. systemd is one row up because it owns<br>login, the network, name resolution and an IPC bus: scope, not refinement. Reading that row<br>as "more advanced" is what turns the comparison into a shouting match. And the top-left<br>cell is empty. Nobody has built a system platform on a one-supervisor-per-service<br>architecture, and 66 is not trying to; see Placement.
What it actually looks like¶
Before the argument, the object. Everything below is the real syntax; a reader who has<br>never seen 66 can judge the rest against it.
A service is one file. Here is a supervised daemon that also re-reads its configuration<br>whenever your configuration management tool rewrites /etc/ssh/sshd_config:
[Main]<br>Type = classic<br>Description = "OpenSSH daemon"<br>Depends = ( network )
[Start]<br>Execute = ( /usr/bin/sshd -D )
[Event]<br>EventType = inotify<br>From = ( sshd-config-watch )<br>Do = reload
Everything about sshd is in the file called sshd, including how it reacts. There is<br>no companion unit beside it.
The [Event] block names a source, and a source is itself a service, of a type that runs<br>no process and only emits:
[Main]<br>Type = event<br>Description = "watch /etc/ssh/sshd_config"<br>EventType = inotify<br>Watch = /etc/ssh/sshd_config<br>On = ( IN_CLOSE_WRITE )
Execute is an execline script by default, but a shebang on its first line switches<br>language: the same daemon in bash or Python is the same file with<br>Execute = (#!/usr/bin/bash …). Bring it up with 66 start sshd; there is no separate<br>parse step, start does it. A logger is attached by default, so 66 status sshd reports<br>the pid, the uptime, the tree it landed in, and the last lines it printed.
That is the shape of the whole system: one INI file per service, groups of services as<br>trees, and a service's reaction written inside the service it concerns.
Who this is for¶
The answer differs depending on which chair you are sitting in, and conflating the two is<br>how these comparisons usually go wrong.
As a user of a distribution that ships 66, there is nothing to take on. Services are<br>installed by packages, they start at boot, and the init system is as invisible as any<br>other. Nothing above is homework: a frontend with no tree named lands in the default tree<br>on its own. You write a file only when you want a service nobody packaged, and then you<br>write the ten lines shown above, once.
Good fit if you administer machines you actually reason about: a workstation you tune,<br>a fleet you want reproducible, a container image you want deterministic. Especially if you<br>have ever wanted to know why a machine came up the way it did and found that the only<br>answer available was to run an analyser after the fact. The two things 66 gives you that<br>nothing else here does are a graph frozen before boot and an ecosystem you can move between<br>machines as one artefact.
Good fit if you build a distribution or an appliance and want the boot sequence to be a<br>reviewable object...