On Fri, May 03, 2019 at 02:53:21AM +0200, Jeff wrote:
> > I have. The "rather artificial and constructed argument"
> > happened to me in real life, and it was a significant inconvenience.
>
> oh no, i hope it was not a remote server ... :-/
> always try things out on a box you have console access to
> or in a vm.
>
> BTW:
>
> what init systems do this list's subscribers use ?
> i use statically linked (musl) BusyBox init (and gettys)
> + mksh (https://www.mirbsd.org/mksh.htm) + s6 + OpenRC
> (v0.34.11, outdated) as default init system.
> i also ran perp but now run everything to be supervised
> under s6, started via a little setup shell script directly from
> /etc/inittab (most "one time tasks" are indeed directly run
> from the inittab file instead of a shell script).
>
Depending on the system:
s6+s6-rc via hand-rolled stageN scripts
s6+s6-rc with heavily modified s6-linux-init v0.x scripts,
s6+s6-rc with very lightly modified s6-linux-init v1.0.0.0 scripts
sysvinit+insserv with most services under a supervisor (s6)
mainline sysvinit+insserv setups
mainline systemd setups
All of these are nominally Debian systems, and all but the systemd
setups are sysvinit-based from a package manager configuration
perspective. Of these I would say that the 1.x s6-linux-init
ecosystem is by far the one I like the best since it's almost as
flexible in the ways that matter as hand-rolled stageN scripts or the
earlier generation of s6-linux-init stuff, with fewer surprises and
sharp edges.
As for my s6-rc setup, it's similar in design to Guillermo's in that I
started from the standard Debian sysvinit-core starting point, figured
out the dependency graph for core system functionality, and then
replicated it in s6-rc. That general core has persisted for some number
of years, though I've gone through several iterations of how that
service set gets represented on disk and what the bundle and trigger
strategy is (read: nothing that I'm really enthusiastic about sharing
because I'm never entirely happy about all of it but I only really
revisit it when I'm building out a new system).
All my skaware stuff gets static built against musl using the
slashpackage convention, mostly because I want to make sure that my core
system is entirely self-contained. I also use the build toolchains that
Laurent provides because those have significantly fewer gotchas and
sharp edges than trying to maintain that yourself across several
systems. One of these days (or months, or whatever) I'll get around to
setting up a local packaging solution so I only have to recompile once
but that day is not today.
Fun Fact: I'm quite possibly the first person beyond Laurent to use
s6-rc, at least outside of a throwaway vm, and maybe the first person to
seriously boot a complex system (a laptop) with s6-svscan as pid1. The
first month or so of s6-rc was very exciting, both in the promise of a
solid service manager for a supervision system and also because every
adjustment to your service db was a reboot and a 50/50 chance of all
hell breaking loose since s6-rc-update wasn't a thing yet. Those were
also the heady days of s6 not having signal redirection, so using it as
an init was similarly action packed.
--
Colin Booth
Received on Tue May 14 2019 - 05:50:07 UTC