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

[Guillermo]

El vie, 29 ene 2021 a las 14:27, Guillermo escribió:
> [...]

Huh. Lots of apostrophes that shouldn't be there, and that I just
couldn't see without a fixed width font...

G.

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

[Guillermo]

El vie, 29 ene 2021 a las 0:07, Casper Ti. Vector escribió:
>
> Not using s6-linux-init has never been an explicit goal, [...]
>
> Currently I do not understand the `s6-linux-init-shutdown(d)' way
> well, so the old-fashioned way is retained at least for now, [...]

Forgive me if I'm misunderstanding aspects of the architecture, but
jugdging from a quick look at the Git repository, I *think* that you
could depend on s6-linux-init (the package):

* You could replace /etc/slew'/init/rc.boot with s6-linux-init (the
program), or a wrapper script around it. s6-linux-init does more or
less the same as the current script, except running load_clock.rc
(which you could do in /etc/slew'/init/rc.init).
* You could move the current /etc/slew/run to
/etc/s6-linux-init/current/run-image when installing slew. I'm not
sure what skalibs' hiercopy() would do if the latter is just a symlink
to the former.
* You could replace /etc/slew'/init/rc.halt with a service directory
for s6-linux-init-shutdownd in /etc/slew'/run/service, just like you
do now for the catch-all logger.
s6-linux-init-shutdownd does more or less the same as the current
script, except running save_log.rc, save_clock.rc and calling swapoff.
You can move that to /etc/slew'/init/rc.fin, or
/etc/s6-linux-init/current/rc.shutdown.final if you must do some of it
after killing all processes and unmounting filesystems.
* You could symlink /etc/s6-linux-init/current/rc.{init,shutdown} to
/etc/slew'/init/rc.{init,fin}, perhaps with some minimal
modifications.
* You could replace calls to s6-svscanctl in
/etc/slew'/run/service/.s6-svscan/SIG* with calls to s6-linux-init-hpr
if you want to be able to do e.g. 'busybox poweroff''.
* You could replace /etc/slew'/run/service/.s6-svscan/finish with
something simpler, instead of being a symlink to
/etc/slew/init/rc.halt.

G.

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

[Laurent Bercot]

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

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

[Casper Ti. Vector]

On Fri, Jan 29, 2021 at 09:57:43AM +, 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] .

> 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

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

[Laurent Bercot]

Currently I do not understand the `s6-linux-init-shutdown(d)' way
well, so the old-fashioned way is retained at least for now, given its
simplicity in implementation and seemingly better flexibility.  Frankly
it is my intuition that the new way costs more than the old way, but
does not provide that much in return.  (Feel free to prove me wrong.)


 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.

 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
all-in-all has just less of a "screwdriver and duct tape" feel than
a bunch of execline (or rc ;)) scripts.

--
 Laurent

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

[Laurent Bercot]

Actually I do visit the CGit web interface fairly often


 Oh, my bad, the links in the skaware documents actually point to
https://git.skarnet.org/something. Fair enough then, I have made
git.skarnet.org an explicit alias to skarnet.org.



 Perhaps I need to batch change all
 references in the UP2020 document to
...


 No need - I'll own that one, and keep the alias explicitly working.
It's not like subdomains are a scarce resource.

--
 Laurent

Re: s6 supervision

[Colin Booth]

On Fri, Jan 29, 2021 at 11:17:00AM +0530, billa chaitanya wrote:
> Hi Team,
> 
> Is there an API/ command in s6 code to get the information of a process and
> its pid by giving the service name that has started the process?
>
I might be misreading your question but s6-svstat /path/to/servicedir I
believe answers your question, at least as far as reading what
s6-supervise knows about (pid, status, time in status, a few other
details). If you're on a system with a functional procfs you can then
use the pid to query most information from /proc/$pid.
> 
> And does s6-svscan/s6-supervise have the knowledge of  service-name&
> process name & process pid so that it can be fetched to another process
> using IPC?
> 
s6-supervise knows the process id of its primary child and as I
mentioned above you can ask it for that information via s6-svstat. It
does not know anything else about the process because it doesn't need
to. However, there are several options to s6-svstat that make output
information in easy-to-parse formats which make follow-on queries to
/proc trivial.

-- 
Colin Booth