On Fri, Jan 29, 2021 at 09:57:43AM +0000, Laurent Bercot wrote:
> It may cost more *to you*, but there is real and significant value
> in following existing interfaces that people are familiar with. Being
> able to just use "reboot" instead of the, uh, slightly less intuitive
> "s6-svscanctl -6 /run/service" to reboot your machine, is one fewer
> obstacle on the way to mainstream s6 adoption.
But even `s6-reboot' from older s6-linux-init, or `busybox reboot'
with slew can already do that...
> Additionally, and maybe more to your liking, there are also technical
> benefits to never killing s6-svscan. Being able to assume that a
> supervision tree will be operational at all times, including during
> shutdown (and even in stage 4!), is really comfortable, it cuts down
> on a lot of specialcasing, it makes shutdown procedures recoverable,
> integration into various configurations easier (I'm thinking
> containers with or without a catch-all logger, for instance), and
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 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.
[1] <
https://skarnet.org/software/s6/s6-svscan-1.html>.
> 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 :(
--
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Received on Fri Jan 29 2021 - 14:33:36 UTC