Re: [ale] systemd talk from July has slide deck online now

[Guillermo]

2015-09-09 2:04 GMT-03:00 Steve Litt:
>
> If I want to use s6 as my init, what do I do, just put into my Grub
> kernel line init=/usr/bin/s6 or whatever the s6 executable is?

If you want to use the s6-linux-init package and minimum
customization, in addition to s6 and s6-linux-init, you'll need to
download and build two more skarnet.org packages, s6-linux-utils and
s6-portable-utils, and then you can follow the quickstart guide:

http://www.skarnet.org/software/s6-linux-init/quickstart.html

The described procedure however replaces /sbin/init, after backing it
up, with the saved output of s6-linux-init-maker, i.e. /tmp/init,
which is what the s6-linux-init documentation calls "the stage1
script". If you want to go the "new GRUB menu entry" route, it would
change to something like:

(As root)
rm -rf /tmp/s6-linux-init /tmp/s6-stage1-init
s6-linux-init-maker [options] /tmp/s6-linux-init > /tmp/s6-stage1-init
chmod 0700 /tmp/s6-stage1-init
mv /tmp/s6-linux-init /etc
mv /tmp/s6-stage1-init /sbin

The new GRUB menu entry can then pass an 'init=/sbin/s6-stage1-init'
option to the kernel. And you halt, reboot or poweroff the machine
with 's6-svscanctl -st /run/service', 's6-svscanctl -rt /run/service'
or 's6-svscanctl -pt /run/service', respectively. The
s6-linux-init-maker options you may additionally need or want are -d,
-u, -p and -e.

Note that you also need to write two scripts, /etc/rc.init and
/etc/rc.shutdown. These are what the s6-linux-init documentation calls
"the stage2 script" and "the stage3 script". But they serve the same
purpose as the ones in your Suckless Init document, so you already
know what goes in there. There are some notable differences, though:

 * The scan directory is /run/service, not /service, so it will be a
directory in a tmpfs, that is created and populated at boot time with
a (very small) initial set of services by the stage1 script. You then
have to copy or make symbolic links to the service directories you
want, which you would have in a non-volatile "service repository",
like /etc/sv, /var/service, /var/svc.d as OpenRC likes it, etc. and
then do an 's6-svscanctl -a /run/service'. All these actions can be
programmed inside /etc/rc.init.

 * /etc/rc.init will start executing when s6-svscan is already running
as process 1, so you don't need to call any svscanboot-like command at
the end of the script. You just let it finish and return when it's
done. It will be running as a child of s6-svscan and get reaped when
it returns.

 * /etc/rc.shutdown will be called with a single argument: 'halt',
'poweroff' or 'reboot', depending on the requested shutdown mode. And
will run as process 1 when the machine is shutting down, so if it
aborts or exits before executing the final halt, reboot or poweroff,
you'll get a kernel panic. Write it carefully.

 * Inside /etc/rc.shutdown, you can use s6-halt, s6-poweroff and
s6-reboot in place of sysvinit's counterparts. These programs come
with the s6-linux-utils package. And you can use 's6-nuke -t' and
's6-nuke -k' in place of 'killall5 -15' and 'killall5 -9',
respectively. The s6-nuke program comes with the s6-portable-utils
package. This will remove all dependencies on sysvinit-like binaries.
In particular, the ones that expect to talk to process 1 through
/dev/initctl won't even work.

Cheers,
G.

Re: [ale] systemd talk from July has slide deck online now

[Colin Booth]

On Sun, Sep 13, 2015 at 11:43 AM, Guillermo  wrote:
>
> If you don't look too closely, you could also say nosh without the
> userspace terminal and login services stuff more or less covers the
> same ground as s6, s6-rc and a small subset of execline.
>
I mean't more in the "one stop low-level system management" sense.
Also in the design of the nosh unit files (which may be a case of
parallel evolution, my knowledge of the history of nosh is limited at
best). Pholosophicaly it's definitely coming from the daemontools
world.


-- 
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
  --  William Blake

Re: [ale] systemd talk from July has slide deck online now

[Colin Booth]

On Tue, Sep 8, 2015 at 10:04 PM, Steve Litt  wrote:
>
> Is s6-rc something you add to s6, or is it a totally different thing?
>
One more bit about this. s6-rc sits on top of s6 and emits s6-svc and
s6-sudo commands as necessary. For example, a dry run taking down sshd
on my laptop:
root@radon:~# s6-rc -n0 -d change sshd
s6-rc-dryrun: /package/admin/s6/command/s6-svc -dwD -T 0 --
/run/s6/rc/scandir/sshd-srv
s6-rc-dryrun: /package/admin/s6/command/s6-svc -dwD -T 0 --
/run/s6/rc/scandir/sshd-log

Ignoring the s6-rc-dryrun part, I have a bundle named sshd (containing
both sshd-srv and sshd-log). If I tell s6-rc to bring down sshd, it'll
tell s6-svc to stop sshd, wait until sshd has completely exited
(including any ./finish script), and then do the same with the logger.

Larger bundles, such as taking down my entire networking stack, look like this:
root@radon:~# s6-rc -n0 -d change ok-lan
s6-rc-dryrun: /package/admin/s6/command/s6-svc -dwD -T 0 --
/run/s6/rc/scandir/sshd-srv
s6-rc-dryrun: /package/admin/s6/command/s6-svc -dwD -T 0 --
/run/s6/rc/scandir/ntpd-srv
s6-rc-dryrun: /package/admin/s6/command/s6-svc -dwD -T 0 --
/run/s6/rc/scandir/ntpd-log
s6-rc-dryrun: /package/admin/s6/command/s6-svc -dwD -T 0 --
/run/s6/rc/scandir/dnsmasq-srv
s6-rc-dryrun: /package/admin/s6/command/s6-svc -dwD -T 0 --
/run/s6/rc/scandir/sshd-log
s6-rc-dryrun: /package/admin/s6/command/s6-svc -dwD -T 0 --
/run/s6/rc/scandir/wicd-srv
s6-rc-dryrun: /package/admin/s6/command/s6-svc -dwD -T 0 --
/run/s6/rc/scandir/dnsmasq-log
s6-rc-dryrun: /package/admin/s6/command/s6-svc -dwD -T 0 --
/run/s6/rc/scandir/wicd-log

In this case it takes down the two leaf services that nothing depends
on (sshd-srv and ntpd-srv), then stops the services that are now the
leaf services (sshd-log, ntpd-log, dnsmasq-srv), then the next new
leaf services (wicd-srv, dnsmasq-log), and finally the lone wicd-log
that nothing depends on.

Startup is, predictably the opposite:
root@radon:~# s6-rc -n1000 -u change ok-lan
s6-rc-dryrun: /package/admin/s6/command/s6-svc -uwu -T 0 --
/run/s6/rc/scandir/wicd-log
s6-rc-dryrun: /package/admin/s6/command/s6-svc -uwu -T 0 --
/run/s6/rc/scandir/sshd-log
s6-rc-dryrun: /package/admin/s6/command/s6-svc -uwu -T 0 --
/run/s6/rc/scandir/ntpd-log
s6-rc-dryrun: /package/admin/s6/command/s6-svc -uwu -T 0 --
/run/s6/rc/scandir/dnsmasq-log
s6-rc-dryrun: /package/admin/s6/command/s6-svc -uwu -T 0 --
/run/s6/rc/scandir/wicd-srv
s6-rc-dryrun: /package/admin/s6/command/s6-svc -uwu -T 0 --
/run/s6/rc/scandir/sshd-srv
s6-rc-dryrun: /package/admin/s6/command/s6-svc -uwu -T 0 --
/run/s6/rc/scandir/dnsmasq-srv
s6-rc-dryrun: /package/admin/s6/command/s6-svc -uwu -T 0 --
/run/s6/rc/scandir/ntpd-srv

You may notice that the ordering on loggers vs other services is
different. That's because loggers don't depend on anything changing in
this example so s6-rc will get those running first before attending to
anything else.

Cheers!

-- 
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
  --  William Blake

RE: [ale] systemd talk from July has slide deck online now

[James Powell]

That support does launch s6, granted, but what I'm getting at is this:

Use OpenRC to launch each individual service with a wrapped s6 service script 
using a sort of stacked runlevel schema. Each service launches against s6, but 
rather than be controlled strictly by s6, it's controlled through OpenRC with 
the exception of the supervisor which can restart a failed service using s6 
while still maintaining control through OpenRC.

-James

From: post-sysv<mailto:boycottsyst...@openmailbox.org>
Sent: ‎9/‎8/‎2015 9:01 PM
To: a...@ale.org<mailto:a...@ale.org>
Cc: supervision@list.skarnet.org<mailto:supervision@list.skarnet.org>
Subject: Re: [ale] systemd talk from July has slide deck online now

On 09/08/2015 11:44 PM, James Powell wrote:
> I have wondered if OpenRC could have scripts that hook into s6 to start 
> services via s6 and run in supervision mode while having OpenRC manage order 
> of process startup and sysvinit handles the remainder of init functionality. 
> In a way you combine sysvinit, OpenRC, and s6 in a harmonious union. It's one 
> way of doing things, but it does give insight into mixing different services 
> to run a system.

OpenRC, since 0.16, *does* in fact support s6 integration:
https://github.com/OpenRC/openrc/blob/master/s6-guide.md

Re: [ale] systemd talk from July has slide deck online now

[Laurent Bercot]

I am unfamiliar with those. Do they all start Linux?
My goal was more to show what systemd does different from prior Linux
startups for the major distros.


 I was just made aware of that article:
 http://blog.darknedgy.net/technology/2015/09/05/0/

 It's a pretty comprehensive list of the init systems for Linux.

--
 Laurent

Re: [ale] systemd talk from July has slide deck online now

[Avery Payne]

On 9/9/2015 9:57 AM, Laurent Bercot wrote:

 Quoting the document: "This article is not meant to impart any technical
judgments, but to simply document what has been done".

 I don't think the author of the document is condoning XML configuration
any more than you and I are. (Context: VR is also the author of uselessd
and he eventually gave up on it because systemd was just too complex to
redesign.)



With regard to the redesign, I've noticed an ongoing method of derailing 
systemd discussion.  I'm only going to digress from the mailing list for 
a brief moment to point out this recurring format:


User1: "I don't like systemd that much because of reason X" (where 
reason X may or may not be a legitimate reason to dislike it)

User2: "Go design a better systemd"

Notice how the discussion is turned back to systemd directly.  It's 
always "go re-invent it", not "make something different".  I just wanted 
to point that out.


P.S. because of the flammable nature of this topic, please, do NOT 
respond to my posting on the mailing list; if you want to respond, send 
an email.

Re: [ale] systemd talk from July has slide deck online now

[Laurent Bercot]

On 09/09/2015 18:45, Steve Litt wrote:

Several of those inits required services to be configured in XML.

Tell me one more time just so I understand: Why would *anybody*
configure their services with XML, thereby requiring the init system to
have a built in XML parser? XML parser in PID1, what could possibly go
wrong?


 Quoting the document: "This article is not meant to impart any technical
judgments, but to simply document what has been done".

 I don't think the author of the document is condoning XML configuration
any more than you and I are. (Context: VR is also the author of uselessd
and he eventually gave up on it because systemd was just too complex to
redesign.)

--
 Laurent

Re: [ale] systemd talk from July has slide deck online now

[Steve Litt]

On Wed, 9 Sep 2015 18:03:52 +0200
Laurent Bercot  wrote:

> >> I am unfamiliar with those. Do they all start Linux?
> >> My goal was more to show what systemd does different from prior
> >> Linux startups for the major distros.
> 
>   I was just made aware of that article:
>   http://blog.darknedgy.net/technology/2015/09/05/0/
> 
>   It's a pretty comprehensive list of the init systems for Linux.

Several of those inits required services to be configured in XML.

Tell me one more time just so I understand: Why would *anybody*
configure their services with XML, thereby requiring the init system to
have a built in XML parser? XML parser in PID1, what could possibly go
wrong?

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

Re: [ale] systemd talk from July has slide deck online now

[Steve Litt]

On Mon, 7 Sep 2015 14:59:08 -0400
Jim Kinney  wrote:

> On Sep 7, 2015 1:43 PM, "Steve Litt" 
> wrote:
> 
> > On Mon, 07 Sep 2015 11:21:24 -0400
> > Jim Kinney  wrote:
> >
> > > http://ale.org/?p=632
> > >
> > > The slides are now added to the bottom of the announcement page.
> >
> > Hi Jim,
> >
> > I think for your next presentation, you should either get rid of all
> > comparisons to sysvinit and Upstart, or include comparisons to
> > runit, OpenRC, Epoch, Suckless Init plus s6 plus LittKit, Suckless
> > Init plus daemontools-encore plus LittKit, and the soon to be
> > published s6-rc.
> >
> > If your presentation is simply "how to use systemd", you need no
> > comparisons. If your presentation includes "why systemd is better",
> > it would be misleading not to include the many excellent init
> > systems available.

> I am unfamiliar with those. Do they all start Linux?
> 
> My goal was more to show what systemd does different from prior Linux
> startups for the major distros.

Hi Jim,

Fair enough. Still, your comparison to only upstart and sysvinit could
be misconstrued to mean it's the best init system. In fact, I'm
pretty sure the systemd industry and fans will quote your
presentation as proof of systemd being the best init.

Here are some of the many good inits:

* runit: Serves as both PID1 and typical daemontools-style service
  manager.

* s6: Very advanced daemontools-style service manager. Requires some
  other PID1. Sysvinit will fill that bill (without any of the init
  scripts: Just one line in /etc/inittab). Personally, I used
  Suckless-Init  to implement PID1, and LittKit to provide
  deterministic startup order of services.

* s6-rc: This is coming out this month: I haven't used it. From what I
  understand, this has raised the bar by combining a top quality PID1
  with the s6 service manager.

* nosh: Another PID1 plus daemontools-style service manager. Its
  runscripts require a special language, I was unable to compile it
  eight months ago. Judging from the many things I've heard its author
  saying, this should be an excellent init if you can get it running.

* Epoch: Trivially easy init system with declarative config file
  instead of init scripts, run scripts, or unit files. If I need to
  alt-init a computer in two hours, I'll be using Epoch.

* OpenRC: A sort of advanced version of what sysvinit should have been.
  I've used it a couple times. I understand it has the ability to do
  all the same stuff as systemd achieves with its socket-activation. Is
  not capable of automatically rerunning crashed services.

* RichFelker + LittKit + daemontools-encore: If you want the simplest
  possible init: One that absolutely anybody can understand and
  troubleshoot, this is it. Includes a 16 lines-of-C PID1. You can
  replace RichFelker with Suckless-Init if you want your PID1 to listen
  for SIGCHLD, SIGINT and SIGUSR1 and do the right thing, substitute
  the 83 lines-of-C Suckless Init. You'll need to write your own
  shutdown script, which isn't particularly difficult. If you want to
  know what RichFelker PID1 is, see the bottom of this page:
  http://ewontfix.com/14/

* Busybox Init: I know little about it.


USE CASES:

The main use for OpenRC, IMHO, is when your distro already comes with
it. Gentoo, Funtoo, Manjaro OpenRC.

Runit and Epoch are high quality, small footprint inits easily
installed on any Linux not tied down with a bunch of systemd-isms. Both
are easy to install, easy to configure, both can rerun crashed
processes (Epoch gives you more choice in the matter). Unless a 1
second bootup is vital to you, I can't forsee a use case not conducive
to Runit and Epoch. Servers, desktops, it's all good. Runit also works
with BSD.

S6 is a top notch service manager that can be combined with a separate
PID1 (sysvinit, Suckless-Init, systemd) to init almost any use case.
Its claim to fame is reliability: You just can't kill it. With the soon
to come s6-rc, it will be a complete init system of the highest quality.

(RichFelker|Suckless-Init) + LittKit + any daemontools-style service
manager is best when your top priority is academic simplicity.
Conforms to http://ewontfix.com/14/. It can be used to alt-init pretty
much any Linux OS not glued down with systemd-isms, and it will do a
good job as such. In reality, these kinds of inits serve more as
demonstrations: For a production machine you'd probably use runit or
s6-rc instead.

Busybox Init is used when the priority is tiny and simple. 

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

RE: [ale] systemd talk from July has slide deck online now

[James Powell]

I have wondered if OpenRC could have scripts that hook into s6 to start 
services via s6 and run in supervision mode while having OpenRC manage order of 
process startup and sysvinit handles the remainder of init functionality. In a 
way you combine sysvinit, OpenRC, and s6 in a harmonious union. It's one way of 
doing things, but it does give insight into mixing different services to run a 
system.

-James

From: Colin Booth<mailto:cathe...@gmail.com>
Sent: ‎9/‎8/‎2015 6:22 PM
To: a...@ale.org<mailto:a...@ale.org>; 
supervision@list.skarnet.org<mailto:supervision@list.skarnet.org>
Subject: Re: [ale] systemd talk from July has slide deck online now

> Hi Jim,
>
> Here are some of the many good inits:
>
> * runit: Serves as both PID1 and typical daemontools-style service
>   manager.
>
Runit is a pid1 init, which runs a service manager as a non-pid1
supervision tree root. runit runs a script called `1' to handle all
post-boot initialization oneshots, followed by a script called `2'
which serves to exec into your supervision scanner (runsvdir), and
runs `3' to handle all system teardown.
>
> * s6: Very advanced daemontools-style service manager. Requires some
>   other PID1. Sysvinit will fill that bill (without any of the init
>   scripts: Just one line in /etc/inittab). Personally, I used
>   Suckless-Init  to implement PID1, and LittKit to provide
>   deterministic startup order of services.
>
s6-svscan is designed to be a stage 2 init and supervision root but
can happily run as a non-init process under another service. Compared
to runit, where pid1 is runit, and it forks out different scripts for
each stage, when run as an init s6 uses a script for stage 1, execs
into s6-svscan for stage 2, and uses a script again for stage 3. I use
s6-svscan as an init at home and as a runsvdir/svscan (daemontools)
non-pid1 supervision scanner at work.
>
> * s6-rc: This is coming out this month: I haven't used it. From what I
>   understand, this has raised the bar by combining a top quality PID1
>   with the s6 service manager.
>
s6-rc has nothing to do with pid1 init and everything to do with
solving some major problems that supervision suites have. The base s6
service already handles init if you want it to. s6-rc is a system for
handling service ordering dependencies and the ability to call oneshot
scripts from inside of a supervision context. It is true that s6-init
is a lot friendlier when coupled with s6-rc since it allows you to
move most system initialization out of the very delicate stage1
period, but to say it's an init system for s6 does both s6 and itself
a disservice. If anything, s6 is the init and supervisor, s6-rc is the
service manager.
>
> * nosh: Another PID1 plus daemontools-style service manager. Its
>   runscripts require a special language, I was unable to compile it
>   eight months ago. Judging from the many things I've heard its author
>   saying, this should be an excellent init if you can get it running.
>
As far as I know it, nosh started as a new-school init for FreeBSD,
since launchd was never going to happen, and upstart was linux-only.
As it stands, nosh is playing in the same space as upstart, launchd,
and systemd. I haven't used it (I use bsd init + s6 on my one freebsd
system, and straight bsd init on my openbsd router) but I'm sure its
solid.
>
> * Epoch: Trivially easy init system with declarative config file
>   instead of init scripts, run scripts, or unit files. If I need to
>   alt-init a computer in two hours, I'll be using Epoch.
>
I haven't used it but epoch would make a great init for a supervisor
that wasn't capable of doing that itself. daemontools or
daemontools-encore would do great with epoch sicne 95+% of your
non-boot stuff will be handled by daemontools already. Jonathan, feel
free to correct me if I'm wrong.
>
> * OpenRC: A sort of advanced version of what sysvinit should have been.
>   I've used it a couple times. I understand it has the ability to do
>   all the same stuff as systemd achieves with its socket-activation. Is
>   not capable of automatically rerunning crashed services.
>
OpenRC is a service manager that handles the service half of init
(your rc scripts). It isn't a pid1 but instead hooks into your init,
supervisors, etc to manage service grouping, ordering, and the like.
>
> * RichFelker + LittKit + daemontools-encore: If you want the simplest
>   possible init: One that absolutely anybody can understand and
>   troubleshoot, this is it. Includes a 16 lines-of-C PID1. You can
>   replace RichFelker with Suckless-Init if you want your PID1 to listen
>   for SIGCHLD, SIGINT and SIGUSR1 and do the right thing, substitute
>   the 83 lines-of-C Suckless Init. You'll need to write your own
>   shutdown script, which isn't particularly difficult. If you want to
>   know wha

Re: [ale] systemd talk from July has slide deck online now

[post-sysv]

On 09/08/2015 11:44 PM, James Powell wrote:

I have wondered if OpenRC could have scripts that hook into s6 to start 
services via s6 and run in supervision mode while having OpenRC manage order of 
process startup and sysvinit handles the remainder of init functionality. In a 
way you combine sysvinit, OpenRC, and s6 in a harmonious union. It's one way of 
doing things, but it does give insight into mixing different services to run a 
system.


OpenRC, since 0.16, *does* in fact support s6 integration: 
https://github.com/OpenRC/openrc/blob/master/s6-guide.md

Re: [ale] systemd talk from July has slide deck online now

[Colin Booth]

On Tue, Sep 8, 2015 at 10:04 PM, Steve Litt  wrote:
> Thanks Colin,
>
> I used Suckless-Init as PID1 and had Suckless-Init pass the baton to
> s6, using LittKit to enable service startup ordering in s6 and
> intermixing oneshots and longruns in s6.
>
> If I want to use s6 as my init, what do I do, just put into my Grub
> kernel line init=/usr/bin/s6 or whatever the s6 executable is?
>
You'd write a stage1 script similar to the one in
s6/examples/ROOT/etc/s6-init and write init=/path/to/that/file in your
grub line. Basically, that file does all your pre-supervision stuff,
then execs into s6-svscan, making your supervision root also your PID1
(sort of a best-of-both-worlds, and part of why s6-svscan is designed
to be so bomb-proof). The s6-linux-init-builder project on Laurent's
site automates generating that file.
>
> Is s6-rc something you add to s6, or is it a totally different thing?
>
Different-ish. You set up all your services (oneshots and longruns),
set their dependencies, and then compile a s6-rc dependency db and
service directory. After that point, if you want to do
dependency-aware service changes, you use s6-rc commands, and if you
need to take something down temporarily you use s6-svc or s6-rc
depending on if you want to pull down a set of services or not. It's
available to play with if you want to try it out (I've been using it
since it was first available in mid July, and we've squashed a LOT of
bugs). The program for updating a live system without some surgery
isn't available yet, which is why it hasn't been officially released,
but it totally works.
>
> Am I understanding you right that s6-rc enables you to order the
> startup of managed services, and intermingle those managed services
> with one-shots, as necessary?
>
Yup. A longrun can depend on a oneshot for environmental prep, which
can in turn depend on a different longrun having started and signaled
the system via the s6-ftrig-* notification framework.
>
> Also, am I understanding you correctly that, when used as an init, s6
> starts by running a stage 1 script, then execs itself into a
> supervision program, and when the user chooses to shut down, runs the
> shutdown script? If all of the above is true, it sounds challenging to
> run the wait loop, to reap zombies and receive signals, in the same
> PID1 that is the service manager. I guess I'll have to read the code.
>
When triggered, s6-svscan tells all s6-supervise processes to
terminate their services and then execs into another script to handle
shutdown proper. A reference script for stage 3 is also in the
examples directory. All that said, it isn't that bad combining the two
into your pid1, you just have to make sure you don't tell it to
terminate with s6-svscanctl. Honestly, runit or sysvinit have to
handle the same dual juggling of tasks - in runit's case though it
only needs to supervise one program (runsvdir) but sysvinit has to
supervise everything defined in its inittab so it's a similar level of
complexity (more actually, because sysvinit does more than just reap
and supervise).

Cheers!


-- 
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
  --  William Blake