supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Colin Booth <colin@heliocat.net>
To: supervision@list.skarnet.org
Subject: Re: what init systems do you use ?
Date: Tue, 14 May 2019 05:50:07 +0000	[thread overview]
Message-ID: <20190514055007.hdgghme3mkwgfbud@cathexis.xen.prgmr.com> (raw)
In-Reply-To: <15692301556844801@iva7-b6ed732000ae.qloud-c.yandex.net>

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


  parent reply	other threads:[~2019-05-14  5:50 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-29 19:19 interesting claims Jeff
2019-04-30  2:49 ` Guillermo
2019-04-30  8:22 ` Laurent Bercot
2019-05-03  0:53   ` what init systems do you use ? Jeff
2019-05-11 18:45     ` Guillermo
2019-05-13 19:13     ` multiplexd
2019-05-13 20:36       ` Laurent Bercot
2019-05-13 21:09       ` Steve Litt
2019-05-14  2:34         ` Guillermo
2019-05-13 21:16       ` Joshua Ismael Haase Hernández
2019-05-14  5:50     ` Colin Booth [this message]
2019-05-14  7:15       ` eric vidal
2019-04-30  8:47 ` interesting claims Jonathan de Boyne Pollard
2019-05-01  7:26 ` Steve Litt
2019-05-01  7:33 ` Steve Litt
2019-05-01 18:13   ` Laurent Bercot
2019-05-15 17:22     ` Steve Litt
2019-05-15 23:22       ` Oliver Schad
2019-05-16  1:07         ` Steve Litt
2019-05-16  5:36           ` fungal-net
2019-05-16  8:32             ` Laurent Bercot
2019-05-16 17:10               ` Jeff
2019-05-17  0:23               ` Dewayne Geraghty
2019-05-17 11:21               ` fungal-net
2019-05-17 22:57                 ` Guillermo
2019-05-18  0:52                   ` Jeff
2019-05-18 16:26                     ` fungal-net
2019-05-18 20:04                       ` Guillermo
2019-05-19 11:24                         ` fungal-net
2019-05-19 12:57                           ` killall test run Jeff
2019-05-19 17:29                             ` Colin Booth
2019-05-19 20:39                             ` Guillermo
2019-05-19 23:06                               ` Laurent Bercot
2019-05-19 20:35                           ` interesting claims Guillermo
2019-05-03  1:37   ` how to handle system shutdown ? Jeff
2019-05-03 19:25     ` Laurent Bercot
2019-05-05  0:52       ` is it required to call kill() from process #1 ? Jeff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190514055007.hdgghme3mkwgfbud@cathexis.xen.prgmr.com \
    --to=colin@heliocat.net \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).