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