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

Reply via email to