Email or username:

Password:

Forgot your password?
Ariadne Conill 🐰's posts Post Back to profile
Top-level
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 | Wall-to-wall | Open on hachyderm.io
7 comments
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