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

--5PGjGRPeFWOjWKAG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

Guillermo schrob:
> 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.

Well, you can certainly do that in the way described (by you and other
replies).

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. ;-)

My approach therefore would be a single oneshot repeatedly running
"mount -a" and invoking the appropriate cryptsetup/mdraid/...
incantations on relevant devices, until either "mount -a" is happy or
nothing has changed for long enough that you decide to give up.

If you use "udevadm monitor" to watch for newly appearing devices and
trigger things in response, that should be as fast as possible, no
explicit ordering knowledge needed.
(If udev udev rules weren't such a horror, it would be even nicer to use
those to automatically trigger the decrypting/assembling/... of any
newly appearing device.)


The thing you're losing with this approach is being able to manage the
mounted/unlocked/... state of your devices with s6 commands.
(I tend to think that's actually an advantage, but YMMV.)

HTH,
    Jan

--5PGjGRPeFWOjWKAG
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEFzbVDxcLcKaSI7wVKV5wPm0dL88FAmoMof0ACgkQKV5wPm0d
L88ePQ/9FfPHjYqUa1DKSxpsxjl9zNrtvX8FOO0Jdw7eAJbAz54aj6nnMM9kfymw
9BTRDWWTuoHOd7bWNzN2Enq9pf8RjKY2UU9z7gb7Dq95P+LsDAj3wiCxlCyAbCUP
9MxJgbxRh2hL44bTImaGI0k4iZiyP/1JzODRhvaze2JiZcOs3+b9jum2T9Vv9jlw
K/cyoaOv/r6X1lw5DFT9nYWDLW+MV+/l6dCu74xsouZ82jyCUL3V/MnJ0RN3v/iv
2bOOm3D27mNsopFjXcG25KPI2t2WnUT7gCUjCNkv2DhliJVI82n46V4X3eqWdW2x
OBK4Sd70yJDaTucnBb56Do5nyKyWJMaiX/YCzI0Oq4/7A5zyV/4m9oM48pTE8how
yBmJ5+mgCuI2gHmUKV1tiYkC70Zj6MjhepjqhOuBREzKTt92EwR2KR7z7/5CyDtb
rPkj4W0VcpxI1pInzCnIfBJQDU4h1qoEO29V2OM+NBaX7hhQHVLfV/vaoOg2X68J
xwswU/2/WLIPKuOV7Cw9EgnFkCOYubUOu3e4IWTCDQe7c5UyVwNvt95dO+GaG4mE
MdW6dCyZzvAglimPmgLuuogwtLrGnMa9WL/3EZCc0aNDIrtEJhM9fYfzzcR0BpRe
E9xfjg8brZG2Hii2BJ9dQSURUtI8jBQ5M74ox8i1yZtaMgr7m54=
=thpb
-----END PGP SIGNATURE-----

--5PGjGRPeFWOjWKAG--