Re: nosh: service-dt-scanner gets repeatedly killed by SIGABRT

From: Guillermo <gdiazhartusch_at_gmail.com>
Date: Wed, 8 Jul 2015 21:40:06 -0300

Hi Jonathan,

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:. 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

2015-07-08 5:30 GMT-03:00 Jonathan de Boyne Pollard:
> 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. (-:
Received on Thu Jul 09 2015 - 00:40:06 UTC