Not sure if this is a skaware@ or supervision@ report, but it directly impacts s6 so starting here.
In a setup where the supervise subdirectory of a service is a symlink to some other location (such as with Void where /etc/sv/$svc/supervise is a symlink to /run/runit/supervise.$svc) and that target does not currently exist, attempting to run the service via s6 results in a failure. For example: carbon:~/tmp$ ls service supervise.d carbon:~/tmp$ ls service/ event run supervise carbon:~/tmp$ file service/supervise service/supervise: broken symbolic link to ../supervise.d/supervise carbon:~/tmp$ s6-supervise service/ s6-supervise service/: fatal: unable to mkfifo supervise/control: No such file or directory This appears to be because if mkdir("supervise", 0700) fails with EEXIST s6-supervise then attempts to create the control files. This would be fine except that mkdir() can fail with EEXIST in the case of broken symlinks in which case while the symlink exists, the target does not and the following mknod() calls will not succeed. This issue is fairly easy to work around: either avoiding symlinked control directories or getting the list of symlinked control directories and pre-generating the targets are both easy solutions. The only reason this is an issue is because it's a break from daemontools and runit behavior, both of which attempt to fix broken supervise/ symlinks when encountered. I have a workaround in place for a mostly drop-in replacement on Void from runit to s6 but it doesn't support net new services without a reboot. Obviously the long-term plan is to migrate everything active into s6-rc, but booting on s6-l-i was step one. Cheers! -- Colin Booth