Sorry about that, I accidentally sent this before finishing. So again: 2015-07-08 5:30 GMT-03:00 Jonathan de Boyne Pollard: > > If there's a SIGABRT there should be some error output saying why.
Nope, no error output. I have lauched service-dt-scanner from a shell in the foreground, and to be sure, I also had service-manager (in turn launched from a shell) supervise the service-dt-scanner process and report, using this restart script: #!/bin/execlineb -S0 foreground { echo service-dt-scanner: $1 $2 $3 } exit 1 So both service-manager and service-dt-scanner had their stdout and stderr connected to the terminal, and I should have been able to see any error messages. I did see indeed service-manager's "INFO:" and "DEBUG:" messages. But no messages about why service-dt-scanner died. The shell just said "Aborted", "echo $?" returned 134, and the restart script above said "service-dt-scanner: abort ABRT 6". 2015-07-08 5:30 GMT-03:00 Jonathan de Boyne Pollard: > > 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. I will add that using ls on the scan directory makes service-dt-scanner output this message: "service-dt-scanner: DEBUG: event filter 0 ident 6 fflags 6". So libkqueue does likely generate an event when ls is used on a watched directory. I'll post later what strace had to say. Thank you, G.