Re: s6 talk at FOSDEM 2017: video

[Olivier Brunel]

On Tue, 07 Feb 2017 16:35:37 +
"Laurent Bercot"  wrote:

> >Thing is, I've always thought of anopa as a set of tools, that allow
> >you to set things up however you want. I like that idea, and so
> >that's why it doesn't create service(dir)s on its own, unlike
> >s6-rc.  
> 
>   I totally agree with that philosophy, but all the pressure I'm
> getting is always in the direction of "make it more user-friendly,
> accessible to normal people, integrate it more, more high-level
> commands" - never the other way.

Sure, I get that; And to be clear I wasn't in any way "criticizing"
the magic in s6-rc, just merely explaining why I left it out of anopa.
It certainly is a cool thing from a user POV to have s6-rc handle all
that as simply/easily as it does.

But even though anopa doesn't do this on its own, you're right, I
should probaly have it (that "aa-command" longrun) somehow featured in
anopa, or make it easy for people to use it without having to figure it
out & write it on their own... Still thinking about how I'll do this.

Thanks!

Re: s6 talk at FOSDEM 2017: video

[Laurent Bercot]

Thing is, I've always thought of anopa as a set of tools, that allow
you to set things up however you want. I like that idea, and so that's
why it doesn't create service(dir)s on its own, unlike s6-rc.


 I totally agree with that philosophy, but all the pressure I'm getting
is always in the direction of "make it more user-friendly, accessible to
normal people, integrate it more, more high-level commands" - never
the other way.
 That's why I added magic to s6-rc-compile to make it run a fdholder and
a oneshot-runner automatically as needed: users want the resulting
mechanism without having to concern themselves with the details, so if
the details can be automated, all the better - even if, for you and me,
they're easy to understand and set up manually.

 So if you think an "aa-command" longrun is the proper way to run
oneshots with anopa (a position I obviously agree with) I think you 
should
have it by default in your example service sets, or something of the 
kind.
Few people have the inclination and time to tinker enough to come up 
with

that themselves!



OTOH anopa does come with aa-stage{0..4} scripts, that's true.


 You also have some kind of tty management, which s6-rc doesn't.

--
 Laurent

Re: s6 talk at FOSDEM 2017: video

[Olivier Brunel]

On Mon, 06 Feb 2017 22:44:07 +
"Laurent Bercot"  wrote:

>   I'm obviously partial to s6-rc since it's the one I wrote :) and I'm
> especially proud of the fact that it runs oneshots with the same
> reproducible launch guarantees that it runs longruns with - something
> *no* other service manager does (except integrated init systems since
> those get everything started by pid 1 anyway).

Yeah, it's true that anopa doesn't get that "out of the box", however
it's easy enough to get there: one just needs to create a longrun
service to process start/stop commands, e.g. have a servicedir
aa-command that looks something like:

% cat run
#!/usr/bin/execlineb -P
fdmove -c 2 1
fdmove -c 4 1
fdmove 1 3
s6-ipcserver -1 -- socket
s6-ipcserver-access -i rules --
fdmove 2 4
s6-sudod -2
./aa-command

% cat aa-command
#!/usr/bin/execlineb -s1
ifelse -n { test $1 = start -o $1 = stop -o =1 = reset }
{ if { aa-echo -De "Invalid command: $1" } exit 1 }
if { aa-echo -Dn +w "Running: " +b "aa-${1} $@" }
exec aa-${1} -D $@


And voilà! :) Now to start foobar you'd just do e.g:
s6-sudo /run/services/aa-command/socket start foobar

And aa-start will run in the same predictable environment. In fact,
you could say that's indeed the proper way to do it, and I should add a
note about it in the documentation.

Thing is, I've always thought of anopa as a set of tools, that allow
you to set things up however you want. I like that idea, and so that's
why it doesn't create service(dir)s on its own, unlike s6-rc.

So I'm not sure I want to include a servicedir for aa-command as
described above, bugs me somehow; Just like I know s6-rc has a nice
interface to set up a pipe between services, and that's of course
doable easily w/ anopa, though "less easily" since you need to provide
the e.g. pipe@ & fdholderd servicedirs yourself.

OTOH anopa does come with aa-stage{0..4} scripts, that's true. Somehow
that doesn't really bother me, even if I also think of those more as
examples than anything else (although they're usable as-is w/out issue,
I do so myself.)

Anyhow, that's how one can use anopa and have it run oneshots with the
same reproducible launch guarantees that it runs longruns with. :)

Cheers,

Re: s6 talk at FOSDEM 2017: video

[Laurent Bercot]

Reading the abovementioned link, I still can't figure out exactly what
"service management" is. The part about "bring all services up" and
"bring all services down" sound to me like rc scripts. Is that correct?


 It would be more accurate to say that rc scripts are the old,
traditional way of implementing service management. sysvrc is a
primitive service manager. OpenRC is a better service manager (although
far from perfect).

 Service management is the thing that brings your machine from the
initial "nothing's running" state to the full "my machine is properly
configured and running everything it needs to be running" state, and
vice-versa at shutdown time. rc scripts are one way of doing that; but
they suck, and their suckage is one of the reasons why systemd rose to
power.



the part about "change services' states" sounds like (in runit) the sv
command. Is that correct?


 Yes, partially. For longruns, "sv up" is indeed an appropriate way
of setting the service to the "up" state. For oneshots, however, since
there is no daemon to maintain, the service manager cannot rely on the
process supervision suite to handle the service, so it must bring it
up itself in some way.



You mention that services can be oneshots or longruns. To make it a
longrun, would you just call it with the equivalent of runit's runsv,
from inside the rc file?


 No, if you run a supervisor as a scion of the service manager, it does
not provide a reproducible launch environment. The supervision tree 
should

be spawned by process 1, prior to any invocation of the service manager,
and the service manager should send commands such as "sv up" when
appropriate so longrun services can be started by the supervision tree.

 The implementation of "s6 support" in OpenRC does that exact mistake:
they start s6-svscan as a service managed by OpenRC itself. Instead,
they should assume that a supervision tree already exists, independently
from OpenRC. (That is how s6-rc operates.)



Isn't the proper way to do a runit oneshot to run it from one of the rc
scripts (/etc/runit/1 or /etc/runit/2)?


 Yes, it is. But then it adds ordering constraints: it means you have
to run all your oneshots before starting your process supervisor, i.e.
before running any supervised longrun. This is not flexible enough: for
instance, there are a lot of oneshots that rely on udevd being running;
and udevd is a longrun. Because of that, people who want to run udevd
with runit often simply do not supervise it. (I'm not sure what Void
does; my guess is that they indeed do not supervise it.)

 This is a limitation of runit - and of any supervision suite without a
service manager, really: you cannot order your services exactly how you
want, you cannot express real dependencies, you're forced into a
pattern that does not necessarily fit your needs.

 When you have a real service manager, you can mix-n-match oneshots and
longruns, have oneshots depend on longruns and vice-versa, and still 
have

all your longruns supervised.



The world needs more explanations like the one you give in this
slideshow. One thing I'd like to see is a definitive set of definitions
for service managers and supervision suites. Each definition should
come with plenty of examples and enough redundancy that even the most
unfamiliar can understand exactly what you're talking about.


 Yeah, I only had 15 minutes so I just couldn't get into any details.
In future presentations I hope to have more time, to dive a little
deeper and explain better.



Which do you like more: Anopa, or s6-rc?


 I'm obviously partial to s6-rc since it's the one I wrote :) and I'm
especially proud of the fact that it runs oneshots with the same
reproducible launch guarantees that it runs longruns with - something
*no* other service manager does (except integrated init systems since
those get everything started by pid 1 anyway).

 But anopa also does a few things s6-rc does not, so both have their 
uses.

Go check them out yourself and see which one you prefer!

--
 Laurent

Re: s6 talk at FOSDEM 2017: video

[Jean Louis]

On Mon, Feb 06, 2017 at 02:40:35PM -0500, Steve Litt wrote:
> come with plenty of examples and enough redundancy that even the most
> unfamiliar can understand exactly what you're talking about.

If I may interfere, s6 supervision is not quite adequate for most
unfamiliar, and you are also not in that group.

And video looks like there was just 15 minutes time frame to explain
most important points.

Jean

Re: s6 talk at FOSDEM 2017: video

[Steve Litt]

On Mon, 06 Feb 2017 17:03:00 +
"Laurent Bercot"  wrote:

>   Hello everyone!
> 
>   I'm back from FOSDEM and it was great! Lots of people to meet, lots
> of interesting talks to attend. And I had my own 15 minutes of glory,
> complete with French accent and mic failure! The video has arrived and
> it's available at: 
> https://fosdem.org/2017/schedule/event/s6_supervision/

Reading the abovementioned link, I still can't figure out exactly what
"service management" is. The part about "bring all services up" and
"bring all services down" sound to me like rc scripts. Is that correct?
the part about "change services' states" sounds like (in runit) the sv
command. Is that correct?

You mention that services can be oneshots or longruns. To make it a
longrun, would you just call it with the equivalent of runit's runsv,
from inside the rc file?

You mention the following:

===
Void Linux uses runit without a service
manager; it sometimes needs hacks
(longruns doing nothing) to emulate oneshot
services.
===

Isn't the proper way to do a runit oneshot to run it from one of the rc
scripts (/etc/runit/1 or /etc/runit/2)?

The world needs more explanations like the one you give in this
slideshow. One thing I'd like to see is a definitive set of definitions
for service managers and supervision suites. Each definition should
come with plenty of examples and enough redundancy that even the most
unfamiliar can understand exactly what you're talking about.

Which do you like more: Anopa, or s6-rc?

Thanks for the great doc!

SteveT

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