On Sat, 11 Apr 2015 18:50:12 +0200
Laurent Bercot <ska-supervision_at_skarnet.org> wrote:
> 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.
Dang!!!
Thanks for that reddit reference!
I'm not quite sure why Rich does:
if (fork()) for (;;) wait(&status);
I'm not sure why he repeatedly calls wait() when there's supposed to be
only one direct child. I'd think that if he'd:
if (fork()){
wait(&status);
run_shutdown_code();
}
I'd imagine the preceding would do an orderly shutdown once the child
process terminated. Or, as you mentioned in your reddit reference, the
call to /etc/rc could have all been in a fork()/execvpe(), waitpid()
loop. Still probably less than 30 lines of code. And of course, /etc/rc
would need to know whether this is the first time, during this session,
that it's been invoked, so it can run one-time stuff or not.
Your answers in the reddit reference answered some questions I've had
for a long time. Thank you!
[snip]
>
> 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.
Excellent!
>
> > 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 ?
No. I read that at the time, IIRC, but it didn't help me. Keep in mind,
I was less knowledgeable about init systems back then. But still,
documentation is supposed to work for unknowledgeable people, as long
as they meet some minimum criteria of underlying knowledge.
> 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 ?
Yes, yes, YES!!!
1. Tell me exactly what executable to specify in the init= part of
the kernel line, in order to init to S6. Including path to that
executable.
2. Tell me how to compile the executable that is the answer to
question 1.
3. Tell me where to put the executable that is the answer to
question 1. In this age of symlinks between /bin and /usr/bin, this
is not always a simple question.
4. Tell me the other necessary executables I need to compile, and tell
me how to compile them and where in the directory structure to
place them.
5. Tell me the name and location of the executable I need to use if I
want to use S6 just as a process manager (like daemontools).
This would be an excellent learning step.
6. Tell me how to set up S6 to act as everything but PID1, kind of like
OpenRC does. Tell me the name of the S6 command I need to put
in /etc/inittab (assuming I'm using sysvinit) in order to achieve
"everything but PID1", and whether it should be labeled respawn or
not in /etc/inittab.
As I remember (I tried S6 in November 2014), your compile instructions
were reasonable enough that compile tweaks were discoverable and I
could compile the executables. What was sorely missing was, what is the
executable serving as S6's PID1.
> > 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.
Yes. I'm not even sure what you mean by a command line. Do you mean a 1
liner command that, in bash, would have lots of semicolons and go out
to column 300 or so, or do you mean the command prompt, or something
else?
In summary, the low hanging fruit to make your docs more useful would
be:
1) Tell S6's PID1 executable, where to put it, and give an example on
the grub kernel line.
2) For the person just wanting to use S6 as a process manager (which
could be a much less steep learning curve), identify the process
they should run from the command prompt: The s6 equivelant of
daemontools' svscanboot. Include how to compile it (you probably
already do).
3) This isn't strictly S6's business, but it would help if you could
document a way to discover the filename/location of the *current*
pid1, so I could move it away and put the S6 pid1 in its place,
which is easier than tweaking grub.
Given those three things, and the fact that I could use /bin/sh for the
scripting language if I wanted, I think S6 would be fairly
straightforward to install and use.
Thanks,
SteveT
Steve Litt
Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28
Received on Sat Apr 11 2015 - 18:23:42 UTC