@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...
@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)
@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.
@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.
@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.
@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.
@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?
@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.
@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 https://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.
@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: https://skarnet.org/software/s6/unit-conversion.html
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: https://skarnet.org/software/s6/unit-conversion.html
Gregory's Server
@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...