El vie, 6 feb 2026 a las 0:58, Laurent Bercot escribió:
>
> Long time no see 🙂
Ha, yes, it's been a while.
> A feature that exists in the current git (but not in s6-rc-0.6.0.0)
> will allow service definition overrides: later stores can override
> definitions from earlier stores.
Ah, that's better I think. It would be like systemd, where unit files
in e. g. /etc/systemd/system override files with the same name in
/usr/lib/systemd/system.
> The idea is that a local store could provide its own batch of
> services, independent from the global store. Sysadmins could write
> their own stuff there. The distribution could add some polish that
> cannot be handled by service definitions packaged independently and
> installed by the package manager.
So, for example, say store in /usr/share/s6-frontend/s6-rc/sources is
managed by the distribution, and there's a second store in
/home/guillermo/s6-rc-sources managed by me. The first one should be
usable by itself (i. e. s6-rc-compile should be able to make the
reference database if the repository only used that store), and the
second one would have atomic services not present in the first one,
that can depend on services in either of them. And for next s6-rc,
also maybe overrides for services in the first one. Something like
that?
> I fear this may be a bit brittle, but the onus is on the distro to
> have a consistent view of all the services it packages, and for the
> additional stores, the onus is on the local admin to avoid breaking
> things.
I think that's reasonable.
> >3) Set inconsistencies I: if service A's prescription is "active", A
> >depends on service B, and B's prescription is "usable", does 's6 set check'
> >report that as an inconsistency?
>
> Yes, it should.
And why is that an inconsistency? The only difference is that A would
be in the "default" bundle and B wouldn't, correct? But when 's6
system boot' starts the bundle, A starts because it is in the bundle
contents, but B will start anyway because it is a dependency. This
final machine state looks fine to me, unless there's an expectation
that "usable" prescription should imply "down" state until an explicit
's6 live start'. Which I wouldn't assume from the prescription's
chosen name (and don't remember reading in the documentation). B is
"usable" and "used" in this case.
It would also align with OpenRC, which also starts services that are
"need" dependencies of a service in a runlevel, even if the
dependencies aren't in the runlevel.
> > If service A's prescription is "usable", A
> >depends on service B, and B's prescription is "active", does 's6 set check'
> >report that as an inconsistency?
>
> No, unlike the previous one, that configuration is valid.
OK, that aligns with my expectations then.
> >4) Set inconsistencies II: does 's6 set commit' fail if the commited set
> >has unfixed inconsistencies?
>
> Yes, it will fail (it performs a check before the commit itself).
So, given the answer to 3) it looks to me like 's6 set commit' forbids
some configurations that don't seem to actually create problems.
Trying to think which combinations do create problems, all I can think
of is:
a) {Essential | active | usable} A depends on masked B: because, from
the point of view of s6-rc, it would need to start a nonexistent
service B if it is asked to start A.
b) Essential A depends on {active | usable} service B: because 's6
live stop-everything --without-essentials' does not stop A but would
stop its dependency B.
...which makes me ask: does 's6-rc -da change' stop services not
marked with "flag-essential" in their definitions, that are
dependencies of essential services? Does s6-rc-compile fail or warn if
that happens in the submitted set of services? Unless I'm
misunderstanding the code, it looks like that they don't?
...which makes me ask: isn't GOLB_HIDEESSENTIALS set in s6-rc-0.6.0.0
for the wrong option (-D instead of -d), or am I misunderstanding the
code?
*
https://git.skarnet.org/cgi-bin/cgit.cgi/s6-rc/tree/src/s6-rc/s6-rc.c?h=v0.6.0.0#n495
Also does 's6 live install' fail if the current set never had a
successful 's6 set commit'? There's no compiled database for the set
before that, right?
Thanks,
G.
Received on Sun Feb 08 2026 - 21:57:00 CET