Re: Why is /etc/sv/alsa/supervise a symlink to /run/runit/supervise.alsa

From: Laurent Bercot <ska-supervision_at_skarnet.org>
Date: Sun, 29 Oct 2017 09:58:59 +0000

>In runit on Void Linux, what is the purpose of these supervise dir
>symlinks?

  I don't know Void so I can't tell for sure, but the logical
explanation that comes to mind is the following:

  - Void does not use a copy of the service directories in a tmpfs.
It only has one instance of the service directories, in /etc/sv.
(I don't recommend that setup, in particular because it makes it
difficult to implement a package update without race conditions.)

  - The root filesystem, which includes /etc, can be mounted read-only.
But live service directories need a writable supervise/ subdirectory
to store their state. So, supervise/ cannot be on the root filesystem.

  - A solution to this problem is to have the supervise/ subdirectories
actually be symlinks to a read-write place. /run is such a place.
It means that "supervise" symlinks are dangling, pointing to a
different filesystem; the appropriate directories are created during
early boot, before runsvdir runs, so supervise symlinks are not
dangling but point to real directories by the time runsv processes
use them.

  - This allows Void to have their service directories on a
potentially read-only filesystem while still being suitable for
live use with runsv.


>Are these symlinks a Void Linux implementation thing, or are they
>specified in runit itself?

  It's Void-specific. Neither runit, nor daemontools, nor s6, enforces
policy; if supervise/ exists when the supervisor is run, they don't
care whether it's a symlink or not as long as it points to a writable
directory. (If it doesn't exist, though, it will be created as a real
directory, and if the servicedir is read-only then the supervisor
will fail.)

--
  Laurent
Received on Sun Oct 29 2017 - 09:58:59 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC