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