Re: special s6-svscan/perp(d) catch-all logger service option

["Laurent Bercot" <ska-supervision@skarnet.org>]

[-- Attachment #1: Type: text/plain, Size: 3711 bytes --]

>hello,
>
>i am a new subscriber to this mailing list.

Hi Jeff, and welcome!


>i saw that daemontools-encore svscan provides an option to
>specify a special catch-all logging service for svscan and its child
>supervise processes:
>(...)
>it would be very nice for s6(-svscan) and perp(d) to provide such
>functionality too.

I have good news and bad news.

The bad news is that the way daemontools-encore's svscan manages
its catch-all logger is almost exactly the way I do it in my stage 1
scripts, except it requires ad-hoc code in svscan. So, the same
mechanism, the same functionality, and move the code *into* svscan
instead of *out of* it? yeah, that's gonna be a no for me, dog,
as far as s6 is concerned. (The less code in s6-svscan and
s6-supervise, the better.)

Additionally, the way daemontools-encore does it, the logdir may
or may not be in the scandir. If it is not in the scandir, it will
not be watched by svscan, and if both the supervise process and the
logger die, nothing will ever read the logpipe again and when the
kernel buffer fills up, your supervision tree will eventually freeze.
Whoops.

The good news is that the functionality already exists, can be
implemented without any additional code in s6-svscan, and there
are tools to help you manage the complexity.
It is done by simply having the catch-all logger as a regular
service in the scandir, which ensures it's supervised by svscan,
and performing a little FIFO trickery at svscan start time in order
to redirect its stdout and stderr to a FIFO (that the catch-all
logger will read from). The differences in implementation is that
the logpipe is a FIFO, not an anonymous pipe, and it's held open by
the logger, not by svscan or supervise. Apart from that, it's the
same idea.

You're saying that my implementation makes running s6-svscan under
sysvinit complex because you need 2 lines in /etc/inittab. That is
not true: you only need 1 inittab line, that runs a "mini-stage 1"
script that performs the FIFO trick (as well as any other early
preparation that you need) before executing s6-svscan. If you don't
want to write such a script, you don't have to - you can, for instance,
take inspiration from this one:
https://code.foxkit.us/adelie/packages/blob/8624df0add74c161f045d19b225fb49afd32fa99/system/s6/s6-svscanboot

You're also saying that this implementation makes stage 1 scripts
difficult to write. That is true, and the contents of the above link
prove it: this s6-svscanboot script, and other "stage 1" scripts,
are not easy to come up with unless you're used to juggling with
Unix plumbing.
Fortunately, you don't have to write stage 1 scripts by hand either:
the s6-linux-init package does just that for you.
https://skarnet.org/software/s6-linux-init/

I would recommend you to grab the 0.4.0.1 release of s6-linux-init
and use the stage 1 scripts created by s6-linux-init-maker, either as
is, or as a source of inspiration for your own stage 1 scripts.
Getting a reliable catch-all logger for s6 is *exactly* what
(this version of) s6-linux-init is about.

I would also recommend you, or anyone interested in stage 1 script
creation, to do this sooner rather than later, because a new version
of s6-linux-init is going to be released in less than a week, and it
will be significantly different, and more complex (because more
featureful, with a focus on turnkey sysvinit compatibility, and
palatability for distributions, rather than quick stage 1 script
creation), and stage 1 will be a C program rather than an
execline script, so use 0.4.0.1 if you want a stage 1 script example.

Hope this helps, and good luck!

--
Laurent