It's a patch to svscan. Upon start, after switching to its service directory, the patched svscan tries to get an exclusive lock on a file named .svscan-lock in that directory, and exits immediately with an error if it fails. This is to prevent multiple instances of svscan from running on the same service directory, causing great confusion among the supervise processes.
The latest version is svscan-lock-0.76.patch.
With execline being out, the svscan-lock patch becomes obsolete. Now you can perfectly emulate svscan-lock's behaviour with a simple wrapper script: move svscan to, for instance, svscan.real, and replace svscan by:
#!/command/execlineb -S1
ifthenelse -s { /package/host/skarnet.org/skaembutils/command/test ${#} -ne 0 }
{ define wd $1 } { define wd . }
setlock -n ${wd}/.svscan-lock
/package/host/skarnet.org/skaembutils/command/minargv0 svscan.real $0
$@
Of course, you need both execline and skaembutils for it to work.
POSIX shells don't set $0 as you would like them to, so if you tried to write a shell wrapper script and called for instance exec minargv0 svscan init within a shell, the svscan process would still have been called svscan instead of init - hence the need for the patch. With execline, $0 is properly set, so the wrapper script works.