Re: Some suggestions on old-fashioned usage with s6 2.10.x

From: Casper Ti. Vector <>
Date: Tue, 16 Feb 2021 16:53:23 +0800

On Mon, Feb 15, 2021 at 02:54:52PM +0000, Laurent Bercot wrote:
> The options! The options need to be all compatible. :) And for
> "shutdown", they would never implement a wrapper themselves, I would
> have to do it for them - which is exactly what I did, although it's
> a C program that actually implements shutdown, not a wrapper around an
> atd program I can't assume will be present on the system.

OK, now I understand their excuse. Nevertheless I still do not think
all these necessarily require something like `shutdownd'; even in the
absence of `atd', chainloading a backgrounding timer for `shutdown' is
not a big exercise with execline (which is perhaps exactly what you have
already done in `s6-linux-init-maker').

> What army? By the time the final kill happens, the service manager
> has brought everything down, and shutdownd has cleaned up the scandir,
> only leaving it with what *should* be restarted. You seem to think
> I haven't given these basic things the two minutes of attention they
> deserve.

Sorry then, I did not see that in the documentation; now the scandir
cleanup contributes some additional complexity. Since the mechanism
behind `shutdownd' does not seem to be adequately explained at least to
me, here I explicitly do not conclude this addition is worthy or not.

> Conceptually, the "old-fashioned" approach may be simpler, yes.
> Implementationally, I disagree that it is, and I'll give you a very
> simple example to illustrate it, but it's not the only thing that
> implementations must pay attention to, there are a few other quirks
> that I've stumbled upon and that disappear when s6-svscan remains
> pid 1 until the very end. [...] after ["wait { }"], you need to make
> sure to unmount filesystems immediately [...]

This is not exactly what older s6-linux-init actually do, which has
been mimicked by slew. As long as the procedure between `wait { }' and
`umount' does not produce orphans, the `umount' will be fine. I have
noticed you saying "a shell does not give ordering guarantees when it
gets a SIGCHLD", but it seems to me that the no-orphan requirement can
be verified by ensuring no commands involved gets backgrounded. Of
course, feel free to correct that; more importantly, may I request you
to list the quirks you have encountered? Only by that may we really see
how much the remaining `s6-svscan' brings, in comparison with how much
it takes (see my paragraph above).

> If your shutdown sequence is e.g. written in Lisp, and your Lisp
> interpreter handles pid 1 duties correctly, okay, that's fair, but
> that's *two* programs that need to do it, when one would be enough. [...]
> The fundamental difference is that the current s6-linux-init hardcodes
> a lot of things in stage 1, purposefully. Yes, it is less flexible -
> though you *still* have a stage 1 hook if you really need it - but the
> whole point is to make stage 1 entirely turnkey and foolproof [...]

When mentioning Lisp, I did not mean to imply Lisp interpreters, but
optimising Lisp compilers, which blur the border between scripts and
compiled programs (cf. `fdclose' and `fd_close()'). But you have said
the problem is not about scripting, so we do not disagree on this; with
this background, I do not quite understand your emphasis on stage 1 in
s6-linux-init -- do you mean somewhere that it prepares for `shutdownd'?

> The "screwdriver and duct tape" feel does not come from the fact that
> those are scripts; it comes from the fact that the scripts run in a less
> forgiving environment where they have to provide the necessary guarantees
> themselves, as opposed to keeping using the framework that has been
> running for the whole lifetime of the system and that is still valid and
> helpful, even though for once you have to interact with it and tell it
> to stop supervising some services because we're shutting down - which is
> the exact kind of situation the supervision API was made for.

Now that scripting does not seem to be a major problem (which falsifies
my previous judgement that it was; sorry for that), the only crucial
issue is the costs and benefits of the supervision tree on halting.
So may I again request you to spare some time to explain the detailed
workflow behind `shutdownd', and the actual quirks that a remaining
`s6-svscan' helps to solve? Perhaps current s6-linux-init and older
s6-linux-init (with derivatives like slew) are just software that suit
different niches (eg. sysvinit/systemd-minded audience vs. those who
accept daemontools-ish software well), which would be perfectly fine.

> I also disagree that the script approach is shorter and/or clearer.
> It may be clearer to people who read a script better than a doc page
> (or C code), but I don't think it should matter as long as the doc is
> accurate; if it's not, that's what should be fixed. And the source code
> may be shorter with a scripted stage 1, for sure, but the code paths
> taken by the CPU are way shorter with the C version, and make fewer
> assumptions. I'm confident that the current s6-linux-init breaks in
> significantly fewer situations than its previous incarnation.

Then the `shutdownd' documentation might need to be fixed; BTW, the "Is
it possible to write stage {1,3} init in a scripting language?" sections
from `s6-svscan-1.html' have not seen real changes since 2014 ;)

My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Received on Tue Feb 16 2021 - 08:53:23 UTC

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