Email or username:

Password:

Forgot your password?
Ariadne Conill 🐰's posts Post Back to profile
Top-level
Laurent Bercot

@ariadne @sertonix The reason why s6-rc isn't at usability parity with openrc is because openrc cheats by embedding itself with a shell, which means it's dynamic everywhere, which makes it powerful but very hacky.

Using similar shortcuts would lead to similar results, and getting the same amount of power with a clean infrastructure is *difficult*.

(Edit: typo)

5 March at 21:48 | Wall-to-wall | Open on social.treehouse.systems
16 comments
Ariadne Conill 🐰

@ska @sertonix i meant more basic things like:

s6-rc -D $foo

you are new to alpine. what does this do to the $foo service?

verses:

rc-service $foo —force stop

neither really fit the noun/verb UX that alpine prefers though, which would be something like

servicectl —force stop $foo

5 March at 21:54 | Open on social.treehouse.systems
Laurent Bercot

@ariadne @sertonix if it's only a syntax issue, that's not too hard. I don't think that's it though.

5 March at 21:55 | Open on social.treehouse.systems
Ariadne Conill 🐰

@ska @sertonix syntax is only a single aspect, it also has to do with how the services are configured and so on.

if you look at all of the frontends to s6-rc which exist, like the one that artix uses, you’ll see that they all have coalesced on files which look awfully like systemd’s unit files.

but as i alluded to earlier the key thing really is the event handling, e.g. spawning services only when you actually need them, or shutting down when the power button is pushed. that part is hard, and even systemd doesn’t get it quite right.

@ska @sertonix syntax is only a single aspect, it also has to do with how the services are configured and so on.

if you look at all of the frontends to s6-rc which exist, like the one that artix uses, you’ll see that they all have coalesced on files which look awfully like systemd’s unit files.

but as i alluded to earlier the key thing really is the event handling, e.g. spawning services only when you actually need them, or shutting down when the power button is pushed. that part is hard, and even...

5 March at 22:01 | Open on social.treehouse.systems
Ariadne Conill 🐰

@ska @sertonix (there is also all the icky things that people with good taste hate, like “dbus service activation”, but sadly dbus is here to stay whether anyone wants it or not)

5 March at 22:12 | Open on social.treehouse.systems
Sertonix

@ariadne
@ska
Oh no, not "dbus service activation"! It's awfull. I still have hope to get rid of it.

As far as I could find the way it communicates with systemd is just a hack.

Maybe s6-rc could establish a proper communication.

5 March at 22:29 | Open on fosstodon.org
Laurent Bercot

@ariadne @sertonix the problem with dbus service activation is that dbus is horrible; "service activation" in itself is just on-demand service start, which is reasonable and possible if you couple a supervisor with an event listener. The difficult part of this is dependency management: what do you do if service A is started on-demand but depends on service B? Do you also start service B? recursively? etc.

A lot of issues I have with s6-rc v1 could disappear instantly if we decided that dependencies are not a real thing, and that events can trigger service-local state change. Then I could just couple an event listener with s6 and be done with it!

@ariadne @sertonix the problem with dbus service activation is that dbus is horrible; "service activation" in itself is just on-demand service start, which is reasonable and possible if you couple a supervisor with an event listener. The difficult part of this is dependency management: what do you do if service A is started on-demand but depends on service B? Do you also start service B? recursively? etc.

6 March at 5:57 | Open on social.treehouse.systems
Rich Felker

@ska @ariadne @sertonix Dbus service activation was an intentional bypass of admin/distro policy to launder unsafe automatic launching of services across privilege domains past folks who would say no.

6 March at 6:02 | Open on hachyderm.io
Laurent Bercot

@ariadne @sertonix s6-linux-init does the power button thing and it works, as shown in Adélie.

"Spawning services only when you actually need them" is a part of what s6 and s6-rc do, in their current incarnation; but I think you're thinking of dynamic events, such as those created by a network manager.

It is *difficult* to have a system that is both reactive to dynamic events that can happen in any sequence (such as network events) and that can still give a bootability guarantee and a system state guarantee. Current s6-rc provides the latter, because I think that's essential. Getting it to include dynamic events is another enchilada.

(I need to go to sleep, so I'll stop for tonight.)

@ariadne @sertonix s6-linux-init does the power button thing and it works, as shown in Adélie.

"Spawning services only when you actually need them" is a part of what s6 and s6-rc do, in their current incarnation; but I think you're thinking of dynamic events, such as those created by a network manager.

5 March at 22:14 | Open on social.treehouse.systems
Rich Felker

@ariadne @ska @sertonix If there are multiple aspects, it would be nice to see them separated and handled separately.

Can someone who wants to see Alpine running s6 init out of the box sit down and write some scripts called servicectl etc. with familiar interfaces?

5 March at 23:07 | Open on hachyderm.io
Rich Felker

@ariadne @ska @sertonix The core problem with systemd is that it strongy couples/bundles these things. If you adopt it for the (reasonable, familiar) service management and control interfaces, you get stuck with it renaming your network interfaces, corrupting your logs, etc.

5 March at 23:09 | Open on hachyderm.io
Laurent Bercot

@dalias @ariadne @sertonix The reason why I don't have the s6-frontend interfaces yet ("s6 service foobar start") is that I'm not sure of the semantics they should have wrt dependencies and oneshots. Should individual services be controlled and dependencies be damned? should there be different commands to start/stop/restart individual services and graphs of services? And what does stopping a oneshot mean?

I want things to make sense, to be logical and intuitive; and these questions are only ever answered vaguely by systemd and openrc.

Also, systemd's notion of a service includes stuff like ExecStartPre= and ExecStartPost=, which means it really bundles a few oneshots with the supervised longrun; this doesn't work with pure s6, which is why I need the s6-rc service manager layer over it if people want an equivalent of ExecStartPre= in their service files.

(Edit: typos)

@dalias @ariadne @sertonix The reason why I don't have the s6-frontend interfaces yet ("s6 service foobar start") is that I'm not sure of the semantics they should have wrt dependencies and oneshots. Should individual services be controlled and dependencies be damned? should there be different commands to start/stop/restart individual services and graphs of services? And what does stopping a oneshot mean?

6 March at 6:03 | Open on social.treehouse.systems
Rich Felker

@ska @ariadne @sertonix I suspect you can build it on top of s6 with scripts that look & behave like the systemd commands and use their service files. Even if it's mildly ugly, it's a lot less ugly than adopting systemd instead.

6 March at 6:06 | Open on hachyderm.io
Rich Felker

@ska @ariadne @sertonix This really strikes me as a "perfect being the enemy of good" moment.

6 March at 6:06 | Open on hachyderm.io
Rich Felker replied to Rich

@ska @ariadne @sertonix And no ugliness would have to be official "part of s6", just an integration Alpine could use in acceptably near future.

6 March at 6:07 | Open on hachyderm.io
Laurent Bercot replied to Rich

@dalias @ariadne @sertonix You're obviously right, as evidenced by the lack of progress for Alpine users in the past few years, that perfect is the enemy of the good. At the same time, I don't want to offer yet another half-working piece of software that people are only differently unhappy with. There's a real domain issue to solve, and I want to have it solved.

Like everyone else, you'll say, with a link to xkcd.com/927/ ; but I think I've been pretty successful at that so far, with other software I have written.

Maybe service management is different, because it's just too complex to be solved at once; maybe the tooling needs to be done incrementally. But I need at least an idea of what kind of engine I should be aiming for, what kind of guarantees should be prioritized.

@dalias @ariadne @sertonix You're obviously right, as evidenced by the lack of progress for Alpine users in the past few years, that perfect is the enemy of the good. At the same time, I don't want to offer yet another half-working piece of software that people are only differently unhappy with. There's a real domain issue to solve, and I want to have it solved.

6 March at 6:40 | Open on social.treehouse.systems
Laurent Bercot

@dalias @ariadne @sertonix Using systemd service files is *right out*, because service files are completely global to the system; only a very restricted subset of the directives are service-local. I have done a thorough analysis of systemd.service(5) directives here: skarnet.org/software/s6/unit-c

What I'm aiming for is a similar, but much more restricted declarative syntax. And that isn't even hard to do (just terribly boring), the really difficult part is the underlying engine, having something that can react to dynamic events while still guaranteeing bootability and not being trivially amenable to a broken machine state like systemd and openrc are.

Maybe I'm too old-fashioned, but I really want to figure out the engine before slapping an interface onto it. Not doing that is why we have problems with openrc.

@dalias @ariadne @sertonix Using systemd service files is *right out*, because service files are completely global to the system; only a very restricted subset of the directives are service-local. I have done a thorough analysis of systemd.service(5) directives here: skarnet.org/software/s6/unit-c

6 March at 6:26 | Open on social.treehouse.systems
Go Up