Hi,
Am Sa, Mai 16, 2026 am 11:46:04 -0300 schrieb Guillermo:
>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.
For this kind of things, instead of a localmount service, I’d use a localmount
bundle, whose contents I would change depending on my use case. But since
s6-frontend doesn’t handle bundles, I agree it’s cumbersome. You’d have to
create a localmount bundle manually in one of your earlier repositories and
have it override the distribution-provided one installed in a later repository.
If s6-rc-repo overrides bundles and not just atomic services, which I’m not sure
about.
Hoël
Received on Sat May 16 2026 - 18:08:28 CEST