Re: s6-rc: "situation-dependent" dependencies.d

From: Guillermo <gdiazhartusch_at_gmail.com>
Date: Wed, 20 May 2026 00:41:37 -0300

Hi,

El mar, 19 may 2026 a las 14:46, Jan Braun escribió:
>
> However, since (afaik) none of the invocations involved require starting
> an actual long-lived process, I'd argue that would be (ab)using oneshot
> services to reinvent shell scripting. ;-)

I don't object to moving away from nontrivial shell scripts in the
init system :P

Anyway, for my testing Gentoo computer with LVM logical volumes (but
no LUKS), the problem of mounting filesystems with s6-rc is solved
with an OpenRC-like set of services, and I'm happy about it. The
service database includes "udev" and "udev-trigger" services for doing
the udev magic, an "lvm" oneshot for activating LVM volume groups, a
"fsck" oneshot for checking filesystems in /etc/fstab (which include
those in logical volumes), a "root" oneshot for remounting the root
filesystem read/write if "fsck" succeeded, and a "localmount" oneshot
for mounting filesystems in /etc/fstab with a variation of "mount -a".
With the right dependency specifications, the boot sequence looks
similar to OpenRC's, and the final computer state is the same.

What I wish to highlight, more related to what was discussed in the
Gentoo forums, is that at a surface level this set of services appears
to be shareable, but in reality, not completely.

Silly, simplified representation:

A: "Hey, I have this set of s6-rc service definitions that I use for Gentoo."

# s6 system boot
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service udev: starting
s6-rc: info: service udev successfully started
s6-rc: info: service udev-trigger: starting
s6-rc: info: service udev-trigger successfully started
s6-rc: info: service lvm: starting
s6-rc: info: service lvm successfully started
s6-rc: info: service fsck: starting
s6-rc: info: service fsck successfully started
s6-rc: info: service root: starting
s6-rc: info: service root successfully started
s6-rc: info: service localmount: starting
s6-rc: info: service localmount successfully started

A: "See? It works. Do you want a copy of the service store? Just set
the storelist= line in s6-frontend.conf accordingly."
B: "OK, sure."

# s6 repository init
s6-rc-compile: info: adding sources from
/home/user/.local/share/s6-rc/repository/sources/..atomics:ACGZSu
s6-rc-compile: info: adding sources from
/home/user/.local/share/s6-rc/repository/sources/..bundles:NQJhN8
s6-rc-compile: warning: source
/home/user/.local/share/s6-rc/repository/sources/..bundles:NQJhN8 is
empty
s6-rc-compile: info: making bundles for pipelines
s6-rc-compile: info: resolving bundle names
s6-rc-compile: info: resolving service names
s6-rc-compile: info: writing compiled information to
/home/user/.local/share/s6-rc/repository/compiled/..ref:_at_400000006a0d1a3a035548aa:t2UBP4

# s6 set status
root active
udev-trigger active
lvm active
udev active
localmount active
fsck active

B: "Cool. Oh wait, I don't have LVM logical volumes, so I didn't
install package sys-fs/lvm2."
A: "Well, mask service lvm then."

# s6 set mask lvm
s6-rc-set-change: warning: the following services (depending on the
ones given as arguments, or part of the same pipeline) also need to be
changed to "masked": root localmount fsck

B: "Hmmm."

# s6 set commit
s6-rc-set-commit: fatal: unable to commit: found inconsistent dependencies

B: "Guess that didn't work..."

# s6 set check
s6-rc-set-fix: info: (dry run) in set current of repository
/home/user/.local/share/s6-rc/repository: moving service root from
active to masked
s6-rc-set-fix: info: (dry run) in set current of repository
/home/user/.local/share/s6-rc/repository: moving service localmount
from active to masked
s6-rc-set-fix: info: (dry run) in set current of repository
/home/user/.local/share/s6-rc/repository: moving service fsck from
active to masked

B: "What do you think?"
A: "Hmm, you might have to delete that fsck/dependencies.d/lvm file..."
B: "So you are saying I should modify the service store?"
A: "Uuuuh, I guess? Let me ask..."

G.
Received on Wed May 20 2026 - 05:41:37 CEST

This archive was generated by hypermail 2.4.0 : Wed May 20 2026 - 05:42:33 CEST