flexibeast.space - gemlog - 2021-03-02

s6/66 for init, service supervision and service management

For a while now, i've been using 66 for init, service supervision and service management.

Introduction to 66

66 is actually a frontend for the s6 supervision suite and the s6-rc service management suite.

s6

s6-rc

systemd isn't for me. i'm not necessarily anti-systemd overall[a]; but i don't want systemd for my particular use-case. It feels vastly overengineered for my practical needs, and way too complex for me to be able to get something of a handle on. Having been using Unix-y systems as my daily drivers for almost two and a half decades, i'd prefer to have the option to do some plumbing occasionally if necessary, rather than crossing my fingers and hoping that a massive code base and its magic does what i need it to do.

i used to use runit for init / service supervision / service management[b].

runit

i found runit to be rather good - it certainly felt a lot lighter and comprehensible than systemd, the former perhaps exemplified by the difference in boot times between my old systemd-based Debian system and my runit-based Void system: from ~45s to ~25s[c].

i didn't actually intend to move to 66 - i just wanted to have a play around with it to see what it was like. But having done so, i found no reason to switch back to runit. Some of the things i like:

syslog vs. s6-log

Basically, i'm very happy using s6/66. :-)

Some of the philosophical and technical underpinnings of s6 are described in:

"s6: Why another supervision suite?"

Notification vs. polling

"How do I perform socket activation with s6?"

🏷 ict

Glossary

Gemlog Home

[a] And indeed, i actually feel a fair amount of antipathy towards the particular subset of the anti-systemd crowd that engages in ignorant reflexive tribalism. i've encountered one person who thought that sysctl(8) is a systemd thing (it was introduced by 4.4BSD in the mid-90s), and another who assumed that anything ending in ‘d’ (e.g. named(8)) is a systemd thing. :-/

[b] Another issue with the debates around systemd is that they're often referred to with phrases like “the init wars”, even though init is only one part of the discussion; service supervision, service management and logging are other distinct components. systemd smooshes all these things together.

[c] Although fast boot times aren't something i particularly need or actively seek. Having to wait an extra 20s to get to a login prompt isn't inherently an issue for me.