>But even `s6-reboot' from older s6-linux-init, or `busybox reboot'
>with slew can already do that...
Yes. And as your sharp mind undoubtedly noticed, those commands are
not the same as "reboot".
Which means burden on users.
Yes, I also thought it was a small burden at first, but it's not.
It means that all sysvinit-compatible automation does not work, so
there is some porting work to do. And the gap between "a little work"
and "zero work" is HUGE. It's much bigger than the gap between
"a little work" and "a lot of work".
Bear in mind that my eventual goal for s6 is distro adoption. And
distro maintainers will find any and every excuse to reject it.
Having a "shutdown" command that works exactly like sysvinit's
shutdown is essential, because it deals with a major objection, which
is incompatibility and user-unfriendliness.
>There is some non-trivial trade-off: in short, the existence of the
>supervision tree after stage 2 is by itself a kind of "special case"
>(eg. search for "careful handling" in [1]).
I feel like you misinterpreted my meaning.
The *absence* of a supervision tree after stage 2 is precisely what
requires careful handling, and runit only works because Linux has
that peculiarity that kill -9 -1 does not kill the emitter!
Having a supervision tree in stage 3 actually *helps* with the
late shutdown procedure: shutdownd dies right after the kill (which
would make it usable even on a system without the Linux specialcase)
and is restarted by the supervisor for stage 4.
> I am also thinking about
>an application scenario, where a supervision tree with a new s6 version
>replaces the active tree with an old version. This is somewhat silly:
>it can be a little useful in case of major version bump, but is probably
>better solved by complete reboot to completely get rid of all old things
>(s6 or not, updated together) in the memory.
Yes, upgrading your init without rebooting is generally not worth
it. Note that s6-svscan could still be configured to do that with
clever use of SIG scripts; but restarting the s6-supervise processes
is a pain to do without restarting your whole supervision tree, so
it's probably better to just reboot.
This is the case with every single init out there, so you can't paint
that as a drawback of s6. You can wish it were easier, and I agree
that it would be nice, but the necessary trade-offs to make rebootless
init upgrades viable are very much not worth it.
>> all-in-all has just less of a "screwdriver and duct tape" feel than
>> a bunch of execline (or rc ;)) scripts.
>I am very sorry, but I do feel a strong smell of systemd mindset here :(
A systemd mindset in an attempt to be a drop-in replacement for
sysvinit. Yeah, right.
More seriously, you're being unfair, because you're not locked in
at all. You can use the new s6-linux-init and *still* do everything
you were doing before:
- you can manually edit your run-image
- you can remove the runleveld service (which is only used for
telinit emulation) and even the shutdownd service
- you can write SIG scripts to do shutdowns the preferred way
- I absolutely recommend against doing this, but you *still* have
a place in stage 1 where you can fiddle with things: in the
init script before the call to the s6-linux-init binary.
So basically, all you're complaining about is that s6-linux-init-maker
is not generating your preferred run-image layout out-of-the-box
anymore. Well, you're an advanced user, you know what you are doing;
the knobs and levers are *still all there*. The only binary that
kinda hardcodes things is s6-linux-init itself, and if you give it a
try, I'm pretty sure you'll like it, because there was never any reason
to modify the core of stage 1 in the first place and what it does is
what any kind of stage 1 needs to do, no matter what language it's
written in.
And if you don't like it, you're still free to ditch the s6-linux-init
package entirely and keep using your own stage 1.
Besides, when systemd advocates paint sysv-rc shell scripts as
"duct tape", they're *right*. sysv-rc (and OpenRC) scripts are loaded
with boilerplate that only exists to compensate for the lack of a
supervision infrastructure, and systemd, like any supervision system,
does away with that. systemd has 99 problems, but rightly calling out
oversized script scaffoldings ain't one. Its disingenuousness lies in
pretending that an overengineered, opaque, all-encompassing, unescapable
framework is better than the duct tape; and I think you'll find that
s6-linux-init isn't quite the monster you seem to believe it is.
--
Laurent
Received on Fri Jan 29 2021 - 15:48:09 UTC