Some very quick things to be going on with:
If there's a SIGABRT there should be some error output saying why. If
there's no error output, crank up strace and see what the last few
system calls are. It's probably worthwhile doing that anyway, in fact.
Having the bundle directory a direct subdirectory of the scan directory,
rather than symbolically linked-to from it, is unusual in the
daemontools world. It's not something that I've personally tested. But
it's not a setup that I've intentionally ruled out, either. What I have
tested is the several variations of bundle directory = service/supervise
directory, because those are the use cases that I expect and backwards
compatibility is important here. Given that I've not observed any such
behaviour as this, even in cases where I've completely messed things up
in testing (such as completely orphaning the service directory of a
running service, for example), I won't be surprised if that turns out to
be merely a trigger for the actual cause of the problem.
This:
Some of the actions that make service-dt-scanner die are using the
service-{control,status,show,is-*} commands on the service, and using ls on its
bundle directory (yeah, listing its contents).
is completely mad. Another process merely listing the contents of the
directory shouldn't be an event visible to service-dt-scanner in the
first place. My immediate suspicion is a (fourth) libkqueue bug. But
let's see that error output first. Just in case. (-:
