Anybody know how to debug things like this?
Eric S. Raymond
esr at thyrsus.com
Fri Jul 15 02:50:58 UTC 2016
Hal Murray <hmurray at megapathdsl.net>:
> > Seems like a situation made for investigating with Mozilla rr.
> Could you please say a bit more? I don't know anything about Mozilla rr.
> Why is that likely to help me in this case?
It's like a symbolic debugger that keeps an execution trace and lets you
step backwards in time. Under rr you could induce the crash, then step back
to the last syscall.
> I think I have tracked down the problem. It's trying to start a new thread.
> The clone syscall wasn't on the list, but we have started new threads before.
> The catch is that the sandboxing doesn't get called until late in the
> initialization procedure. So the first thread gets created before sandboxing
> turns off the clone syscall. If you trigger a second thread, that one dies.
> (My test case for that is closing the lid on a laptop for a short time.)
> It seemed like a good idea to move the sandboxing up earlier. The catch is
> that most of the initialization will get done as ntp rather than root, so
> permissions on devices for refclocks and files like ntp.keys need to be fixed.
> Anybody see any problems with that? I think old versions and ntp classic
> will still work running as root.
I'm worried about it. Not for any specific reason, it just trips my "Danger!
Danger!" sensors. I've got a bad feeling that it might be one of those
'innocuous' changes that come back to bite us in the ass.
I want to ask a different question: why the early thread launch? Can we move
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel