supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Casper Ti. Vector" <caspervector@gmail.com>
To: supervision@list.skarnet.org
Subject: [Announce] s6.rc: a distribution-friendly init/rc framework
Date: Thu, 22 Mar 2018 21:23:34 +0800	[thread overview]
Message-ID: <20180322132334.GA11596@CasperVector> (raw)

[-- Attachment #1: Type: text/plain, Size: 3300 bytes --]

s6.rc [1] is an attempt to bridge the gap between the elegant foundation
provided by s6/s6-rc and an init/rc system that implements the main
functionalities beneficial for distributions.  s6.rc features a
preprocessor that generates source directories for use with s6-rc from
given templates.  The preprocessing procedure is composed of multiple
tiny passes, which makes the preprocessor not only clean and powerful,
but also extensible.  Using the preprocessor, s6.rc supports instanced
supervision, optional dependencies, in-place `up'/`down' scripts,
automatic connection between services and loggers, as well as
package-specific passes that can be plugged into the preprocessing
phase.

[1] <https://gitlab.com/CasperVector/s6rc-dotrc>.

The init part of s6.rc is, in many aspects, similar to what one would
expect from s6-linux-init.  The stage 1/2/3 scripts shipped with s6.rc
additionally support features like setting the time using hwclock(8) or
other means before exec()ing `s6-svscan' (cf. the documentation for the
rationale), duplicating (while writing to `/run/uncaught-logs') verbose
`s6-rc' output to `/dev/console', automatic reboot under certain
circumstances (eg. when required by fsck(8)), and automatically saving
`/run/uncaught-logs/current' on shutdown.

The attached tarball is an s6.rc-based example setup tailored for Alpine
3.7.x; a VM image of the setup is available at [2].  Due to a lack of
expressiveness in execline, most scripts in s6.rc are written for the
Byron Rakitzis implementation [3] of the rc(1) shell from Plan 9, and
static-linked binaries for x86 [4] and x86_64 [5] are available for
download.  See the attachments for SHA512 checksums (signed using my
OpenPGP public key) of the tarball, the VM image and the rc(1) binaries.

[2] <https://drive.google.com/open?id=1x3BM11C5clU9DTGbgsBmaBssMUtMUItM>.
[3] <https://github.com/rakitzis/rc>.
[4] <https://drive.google.com/open?id=0B3FGvKEMCkmXLUJDQll2VFNsNVE>.
[5] <https://drive.google.com/open?id=0B3FGvKEMCkmXMm9odWhVdVR1Znc>.

Of course, this is just the beginning; a lot of work has to be done:

* Although s6.rc can be easily configured to be rock solid, it is fairly
  fragile to PEBKACs: eg. if you accidentally delete `s6.rc' and then
  reboot the system, the system can get into quite serious troubles.
  Sprinkling related scripts with a lot of "if something is unset then
  default to blah" clauses can avoid the problem, but seems to make
  the code bloated.  Is there a better solution?

* Many more service definitions and ancillary files are necessary for
  s6.rc to be useful for the general public instead of just a few users,
  so any contribution / suggestion is welcome.  BTW, I do not consider
  myself to be a really good documentation writer, so please tell me if
  you have a good idea on improving the s6.rc documentation.

* In principle, it is possible to implement something like Gentoo's
  netifrc [6] using s6.rc's preprocessor, and I believe it would be much
  cleaner than netifrc.  However, since I am not exactly familiar with
  the networking stuffs, perhaps it had better be done by someone else.

[6] <https://wiki.gentoo.org/wiki/Netifrc>.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C


[-- Attachment #2: alpine-s6rc-conf.tgz --]
[-- Type: application/x-gtar, Size: 14022 bytes --]

[-- Attachment #3: SHA512SUMS.asc --]
[-- Type: application/pgp-signature, Size: 1474 bytes --]

             reply	other threads:[~2018-03-22 13:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-22 13:23 Casper Ti. Vector [this message]
2018-03-22 15:29 ` Casper Ti. Vector
     [not found] <20180322132334.GA11596@caspervector>
2018-03-22 17:10 ` Laurent Bercot
2018-03-23  4:00   ` Casper Ti. Vector
     [not found]   ` <20180323040022.GA1737@caspervector>
2018-03-23 10:51     ` Laurent Bercot
2018-03-23 13:05       ` Alex Suykov
2018-03-23 13:31         ` Casper Ti. Vector
2018-03-23 14:19         ` Laurent Bercot
2018-03-23 13:20       ` Casper Ti. Vector
2018-03-25  4:57         ` Casper Ti. Vector
     [not found]       ` <20180323132058.GA21692@caspervector>
     [not found]         ` <20180325045750.GA5868@caspervector>
2018-03-25  6:38           ` Laurent Bercot
2018-03-25  9:31             ` Casper Ti. Vector
2019-06-03  9:30   ` Casper Ti. Vector
     [not found]   ` <20190603093041.GA10891@caspervector>
2019-06-03 16:06     ` Laurent Bercot

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=20180322132334.GA11596@CasperVector \
    --to=caspervector@gmail.com \
    --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).