Is there a chance this sort of issue could happen in usual usage? More importantly, how does this work if the file system is read only?

I had a lengthy response typed out, in the browser, then wanted to test something with runit, which promptly killed my user session, and the stuff I wrote. Don't want to type it out again, so I'll keep it brief, feel free to ask for clarification…

Is there a chance this sort of issue could happen in usual usage?

Yes, if you're cleaning up old runlevels and are clumsy about it. Happens usually in already stressfull situations and you want to remove that potential footgun. Keep in mind that this kind of situation will also prevent the selection of the destination runlevel via the kernel command line. This is a problem, if that's your default path of recovering from boot time issues that happen after the kernel launched PID=1.

More importantly, how does this work if the file system is read only?

It will lead to a couple of error messages at boot and that's it. Zero negative impact. However it should be noted thatrunsvchdir itself can't operate if/etc/runit/runsvdir resides on a readonly filesystem (so having/ readonly will also prevent kernel command line target runlevel selection!).

Strictly speaking not initializing/etc/runit/runsvdir to a well defined state upon boot makes graceful error recovery unneccesarily hard. This in fact also applies to the read-only situation. The actual solution would be to haverunsvchdir create the symlinks directly in/run/runit/runsvdir dereferencing to the directories in/etc/runit/runsvdir.That would also in the same stroke deal with the broken/danglingcurrent/previous symlink problem I seeked to address.

Maybe we can do some weird bind-mounting of symlinks. But the more I think about it, the more I'd rather seerunsvchdir to be modified.

I don't have a strong opinion on this.

But, punisheveryone withunlink(2) andlink(2) on
every startup because some people messed up is not nice.

And this will break stateless/etc

This isn't the right fix. What you ought to do is

ln -sf "${runlevel}" /etc/runit/runsvdir/current

in2 in place of therunsvchdir "${runlevel}" that is there now. We aren't reallychanging the runlevel in2, we aresetting it, so the migration that is imposed inrunsvchdir is inappropriate. Also,runsvchdir verifies the existence of the target runlevel directory, but we've already done that in thecmdline loop in2.

If youreally care about a brokenprevious symlink, you could addrm -f /etc/runit/runsvdir/previous (there is no need to test for existence and remove, just force remove) right before thecurrent symlink is made, but why bother? A brokenprevious symlink is irrelevant.

But, punisheveryone withunlink(2) andlink(2)

How is that in any way punishing? Those syscalls are dirt cheap when done on symlinks.

And this will break stateless/etc

It doesn't take my patch for do this, it's already happening as part ofcore-services: