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
