On 11/04/2015 17:36, Steve Litt wrote:
> I always thought the simplest possible init system is Rich Felker's
> init; the one whose listing is at the bottom of this blog entry:
>
> http://ewontfix.com/14/
>
> Theoretically, Rich Felker's init is all you need in order to init,
Actually, this is one of the few times Rich is wrong. :)
He says "start the real init script and then just reap zombies", but
that's not enough. PID 1 should start another program *and supervise it*
(or reboot when that other program dies).
In his example, suppose /etc/rc dies without doing anything. Then the
machine is in a stable state but you cannot interact with it; it has a
pid 1 running and nothing else, waiting for zombies that will never
happen, and you have to hard reboot. Not good.
It is important to make sure there is always at least one way for an
admin to interact with the machine. My posts in the reddit discussion at
http://www.reddit.com/r/linux/comments/2dx7k3/s6_skarnetorg_small_secure_supervision_software/
give more details about why it is needed.
The simplest possible init program is not Rich's init. It is runit.
Runit does exactly what a process 1 must do and not a bit more;
it never leaves your machine in a stable and unusable state as is
the risk with Rich's init.
I chose to deviate from the runit model for s6 and make the init a bit
more complex than is strictly needed because I find it more elegant to
run the supervision tree trunk as process 1. But it's mostly aesthetic
considerations at that point.
> sending all log messages to stdout, I don't know if daemontools can do
> that, but I know daemontools can send all log messages to the same
> file, assuming the daemontools log run scripts are configured to do
> that.
stdout is always used by default, and adding loggers simply redirects
the flux of messages. To get all the messages on stdout, just don't set
up any logging.
There should be an option in s6-overlay that runs s6-svscan without
any logging (except logging the user sets up), so everything goes to
stdout outside the container.
> I'm under the impression that s6 offers use of the execline language as
> a way to avoid bash-isms. I found execline's documentation insufficient
> for me to learn it, but my impression is its purpose is to provide you
> with a language that's less tricky and more determinant and more
> versatile than bash.
The purpose of execline is to give a way to build, manipulate and run
complex Unix command lines without needing to use and understand the
demented shell syntax. The shell may not sound like a big deal, and
for human users, it's not, unless you're a one-track-mind simplicity
zealot like me. But I find myself building more and more command lines
programmatically, and execline makes that easy as pie - and I like pie.
Whereas a shell has quoting and parsing rules that even an American tax
lawyer would have trouble mastering.
Learning execline is by no means mandatory to use s6, though.
Executables are executables, no matter what language they're written in.
I will totally agree that the execline documentation, like the s6
documentation, is lacking extensive examples. I plan to add that at
some point, I just haven't prioritized it yet.
> I think s6 has a documentation problem. I compiled it, but was never
> able to get it to run, mostly because I was unable to find, in the
> docs, what to do after I got it compiled.
Is the recent
http://skarnet.org/software/s6/overview.html helpful
in this regard ? Apart from detailed examples (which will come at
some point), is there anything you think is missing in it, that
would help you figure out what to do ?
> And there were way too few
> examples of execline code, and I couldn't figure out the language logic
> from the descriptive diagrams.
The language logic is "A script is one command line", and everything
follows from that. It assumes familiarity with the command line, and
I agree it could be clearer. I will try to lower the entry barrier by
improving the documentation in the future.
--
Laurent
Received on Sat Apr 11 2015 - 16:50:12 UTC