Hello.
Some weeks ago, s6-rc was discussed in a thread at the Gentoo forums,
and there was a conversation about the way some OpenRC service scripts
were written, and how equivalent behaviour could be realized with
s6-rc. In that context, the following came up when discussing, for
example, the mounting of filesystems at boot time.
It was observed that OpenRC ships a "localmount" service script
responsible for doing that, and that the core of that script was
essentially a 'mount -a' command that reads /etc/fstab. Then, when
discussing how dependencies and service ordering worked for both
service managers, someone asked about different situations involving,
for example, mounting filesystems in LVM logical volumes, or handling
LUKS containers with encrypted LVM physical volumes.
The way I see it, all those are different cases that would have to be
handled by different compiled databases:
* In the case where, for example, all filesystems are in 'plain' hard
disk partitions, the database would simply contain a service or set of
services equivalent to OpenRC's 'localmount', also doing the 'mount
-a' thing.
* In the case where some filesystems are in LVM logical volumes, their
volume group would have to be activated before mount, so the database
would have LVM-related services, which at some point would have to run
a 'vgchange -ay' command, and the 'localmount' equivalent would have a
dependency on the relevant service(s).
* In the case where there are LUKS containers with LVM physical
volumes, they would have to be decrypted before activating their
volume groups, so the database would have cryptsetup-related services,
which at some point would have to run a 'cryptsetup open' command, and
LVM-related services would have a dependency on the relevant
service(s), forming a cryptsetup --> LVM --> localmount chain.
The interesting part is that all those services look like they could
have pretty much the same "action" part ('up' / 'down' / 'run' /
'finish' files) in all situations, like it happens with OpenRC service
scripts, so one could have pre-written definitions suitable for a
service store (in s6-frontend terms), and then one could just submit
to s6-rc-compile only the subset needed for each situation. But then
the fact that different 'dependencies.d' subdirectories would seem to
be needed for the different cases, which are technically also part of
the s6-rc service definitions, comes up.
s6-frontend can help here with the "submit to s6-rc-compile only
what's actually needed" part: one could think of writing, o getting
from somewhere, a complete {cryptsetup, LVM, localmount} set of
definitions, and then change with 's6 set mask' the prescription of
services that are not needed. But there seems to be no way of handling
the dependency problem other than by changing the definitions in the
service store and doing an 's6 repository sync'. I mean, if one builds
a service store for the full LUKS + LVM case, with a cryptsetup -->
LVM --> localmount dependency chain, then e. g. masking the
cryptsetup-related services for the "LVM but no LUKS" case without
also changing the dependencies of the LVM-related services get an
inconsistency error from 's6 set commit'.
Is there really no other way of doing this at the moment other than by
changing definitions in the service repository? Are there any other
approaches for getting the desired s6-rc behaviour I'm not
considering?
Thanks,
G.
Received on Sat May 16 2026 - 16:46:04 CEST