>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