💾 Archived View for republic.circumlunar.space › users › flexibeast › gemlog › 2021-03-02.gmi captured on 2023-04-19 at 23:00:39. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

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-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:

Recent highly-unscientific manual timings of boot resulted in ~22s for 66, ~20s for runit.

66 trees are neato. Trees group related services together, and can be a dependency or a dependent of other trees. i have a ‘network’ tree; the ‘general’ tree starts after the services in the ‘network’ tree have started. Individual trees can be managed independently.

The 66-inservice(1) command provides a nice summary of the status of a service: not just whether or not it's enabled and whether or not it's up, but also things like which tree it's part of, the contents of the script used to start it, and the most recent log entries for the service (if any).

s6's approach to logging.

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.