Re: anopa: init system/service manager built around s6

From: Laurent Bercot <ska-supervision_at_skarnet.org>
Date: Sun, 12 Apr 2015 02:13:08 +0200

On 11/04/2015 20:23, Steve Litt wrote:
> if (fork()) for (;;) wait(&status);
>
> I'm not sure why he repeatedly calls wait() when there's supposed to be
> only one direct child.

  It's the reaper routine, pid 1's main task. PID 1 must reap zombies
constantly, even if it doesn't spawn children itself, because orphaned
processes are reassigned to it all the time.


> Your answers in the reddit reference answered some questions I've had
> for a long time. Thank you!

  You're welcome!


> 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.

  I doubt you read that page "at the time", since I only added it 3 weeks
ago. ;)
  Please read it now and tell me if it helps you.


> 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.

  You didn't find it for a good reason: there's no such executable!
The http://skarnet.org/software/s6/s6-svscan-1.html page explains why,
and what to do. There's an example of a "stage 1 init" script in
examples/ROOT/etc/s6-init.

  A future version of s6 will provide an executable to run as init -
since it seems a major pain point for a lot of people (you are not
alone!)


> 2. Tell me how to compile the executable that is the answer to
> question 1.

  N/A. Typically, what you would use as process 1 is a script. The
script would execute into s6-svscan in the end.


> 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.

  s6 doesn't care. You would put it somewhere on your root filesystem
and that's it. /bin/init, /sbin/init and /etc/init are the usual
conventions.


> 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.

  "./configure && make && sudo make install" does pretty much everything
here. :P


> 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.

  The problem with daemontools' svscanboot is that it uses an external,
unsupervised process - readproctitle - to log svscan's output. I don't
like that approach, because it introduces unreliability - if something
kills readproctitle, you lose your ability to log the supervision tree's
error messages until you restart the whole tree.

  As a first approximation, though, you can simply use s6-svscan as the
program to use in the instructions at
http://skarnet.org/software/s6/s6-svscan-not-1.html


> 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.

  s6-svscan, respawn. There's still the logging issue - SysVinit will
print all your supervision tree's error messages on the system console -
but it will work.


> 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.

  You should give it a try now, with a configure/make/make install build
system (it changed in December 2014) and the overview documentation page.

  The reason why you couldn't find anything about an executable serving as
s6's pid 1 is that there isn't one! And there isn't one because it's hard
to provide one that works in every situation - for one thing, it's not
possible to provide a *portable* one. Users who want to use s6 as process
1, for now, have to write a script to do so, and I can only provide
documentation to help them. But I understand this is not enough, and I'm
working on it, and will have a solution ready in a few months.


> 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?

  I mean a command line as in the argv argument given to the execve()
system call when a new process is created and executed. If you want
to run a simple command like "nice 10 echo blah" in bash, you type
it as is, and it's the same in execline. If you want to run a compound
command in bash, you put lots of semicolons and other barbaric symbols;
but in execline, you don't - you just run a simple command that has the
same effect as your bash compound command.

  For instance, the following command:
  { echo blah; cat /etc/passwd; } | sort -u
is short and sweet, but requires a shell to run, to interpret the
sequence and the pipe. The following command does the same, but
does not need a shell:
  pipeline foreground echo blah "" cat /etc/passwd "" sort -u

  You can't run the former from a C program without invoking a
shell. You'd run /bin/sh -c "{ echo blah..."
  You can run the latter from a C program without invoking a shell.
It's "pre-parsed", if you will.

  The point of execline is that any script can be pre-parsed into a
similar form. That is exactly what the execlineb binary does: it
reads a script, turns it into a command line of the form seen above,
and execs into it.


> 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.

  ls -l /proc/1/exe :)

-- 
  Laurent
Received on Sun Apr 12 2015 - 00:13:08 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC