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: Answers to some GitHub questions
Date: Wed, 6 Jan 2021 18:47:49 +0000	[thread overview]
Message-ID: <20210106184749.GB810@cathexis.xen.prgmr.com> (raw)
In-Reply-To: <X/XPnRCOnMTxAprX@home.lan>

On Wed, Jan 06, 2021 at 04:56:29PM +0200, Alex Efros via supervision wrote:
> Hi!
> 
> Thanks, this was useful reading.
> 
> Is there a migration guide from runit to s6?
> 
> If not, it might be useful to create one with hints how to rewrite
> /etc/runit/{1,3} and runit services in s6-way, what to run instead of
> /sbin/runit-init as kernel's init= param, and what to use instead of
> `runit-init {0,6}` to halt/reboot. Because, you know, while everything
> you've said about runit vs s6 is true, runit is still "just works"… so
> without easy-to-follow guide it's hard to find a motivation to move to s6.
> 
> -- 
> 			WBR, Alex.
I'm working on one actually. I wrote up a how-to/what I did for Void
Linux here:
https://www.reddit.com/r/voidlinux/comments/khn1jy/adventures_in_booting_void_on_s6/

and will be writing a part two in the next few weeks (free time and life
have been getting in the way). 

Part 1 is a "light touch" conversion, it has some shims to get
everything working right but for the most part it's still pretty
runit-based. Part 2 will be a heavier set of changes and will leverage
s6-rc, some run script generators that I've written, and a few other
things to try and make everything work nicer (better backwards
compatibility with the distro packages, better support for the s6
notification framework, and so on).

My long-term (maybe medium term) goal is to get this into a shape where
it is acceptable in the void package mainline as an alternate base
system, get it in there, and then hand off maintainership to someone who
is more central to Void. Longest term is obvious - adjust the part 2 stuff
so that it's acceptable as the default, but that is a long way off and
this is an iterative process.

-- 
Colin Booth

  reply	other threads:[~2021-01-06 18:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-26  0:57 Laurent Bercot
2021-01-06 14:56 ` Alex Efros via supervision
2021-01-06 18:47   ` Colin Booth [this message]
2021-01-09 17:25   ` 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=20210106184749.GB810@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).