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

2015-09-09 Thread 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

2015-09-09 Thread 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
Sent: ‎9/‎8/‎2015 9:01 PM
To: a...@ale.org
Cc: 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

2015-09-09 Thread 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

2015-09-09 Thread 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.

supervision-scripts 2015-08

2015-09-09 Thread Avery Payne 

Done:
- - - -

+ New definitions: clamd, cpufreqd.

+ Definitions are now versioned.  The ./envdir directory is now a 
symlink to another directory that contains the proper definitions for a 
given version of software.  This solves a long standing problem of 
"version 1 is different from version 2, so using the wrong definition 
breaks deployment", is minimally intrusive, only requires one additional 
symlink and directory in the definition's directory, allows for 
deployment on older systems (with older daemons), doesn't conflict with 
anything that I am aware of (at the moment), and keeps with the 
"filesystem is the database" concept.


+ Cleaned up some old references to /sv that should be /svcdef

+ Revised documentation.  Many concepts are being cleaned up and 
reorganized, including integration into state management systems like 
anopa and s6-rc.



In Progress:
- - - -

+ Renaming some of the internal environment variables to be SIG* instead 
of CMD* to better reflect their nature.


+ Create a test environment with various supervisors on it.  The idea is 
to have a minimal image with several boot options; each boot option 
brings up some combination of supervision + state management, i.e. 
OpenRC + (something), runit, s6 + s6-rc, etc.  So I would select an 
option and boot...and see the results.


+ More definitions.  I've noticed that I've reduced the flow of new 
entries to a trickle since I have had other commitments.  I need to make 
more; the project is nearly at a standstill but a lot of work is still 
needed.  At a minimum, one definition a week should be obtainable; 
ideally, I would like 4 a week.  To the few people who have been 
watching, yes, the project continues, no, it isn't dead.



To Do:
- - - -
Everything.

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

2015-09-09 Thread 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

2015-09-09 Thread 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