s6-svscan catch-all logger service

[Jeff <sysinit@yandex.com>]

26.04.2019, 01:10, "Laurent Bercot" <ska-supervision@skarnet.org>:
> 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.

but this "ad-hoc code" is in C and does not require any execline tricks.
for those to work you need execline installed too.
that way daemontools-encore's svscan can easily get directly started
and supervised by process #1 without any effort.

i think this feature does not require too much "ad-hoc" C code in
the svscan source. it is easy to do that in C while it becomes hard
to impossible do write a shell script that does it (ok, in execline
this seems to be possible, but you need that package installed then).
  
> Additionally, the way daemontools-encore does it, the logdir may
> or may not be in the scandir.

really ? i always used a service subdir of the scandir and it worked
very well.

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

pretty artificial counter example since noone will use a service dir
outside the scandir. i do not know if this is even possible ...
in any case doing so seems very odd to me and was probably
not intended by the author.

> and performing a little FIFO trickery at svscan start time in order

see ? "a little trickery" is necessary here.

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

using a fifo here is IMO not the best solution when using a simple pipe(2)
would suffice since fifos need read-write access to fs they reside on.

> You're saying that my implementation makes running s6-svscan under
> sysvinit complex because you need 2 lines in /etc/inittab.

that was just a general remark not specific to SysV, busybox or 
toybox init that applies to every process #1 (and also to init stage 1
when using s6-svscan as stage 2)

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

yes that works but introduces an extra step of indirection. and again this
seems to require execline.
it becomes more difficult doing so directly from -say- inittab or its
actual equivalent for the given init system.

> You're also saying that this implementation makes stage 1 scripts
> difficult to write. That is true

indeed.

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

i see.

> and it will be significantly different, and more complex
> (because more featureful,
> with a focus on turnkey sysvinit compatibility

who needs such compatibility anyway ?
those who want/need it should run SysV init directly
and start s6 per init script/inittab entry.

> stage 1 will be a C program rather than an execline script

nice ! that sounds really interesting to me.
you have suprised and teased me definitely with this
announcement.

good luck.