Anybody know how to debug things like this?

[Eric S. Raymond]

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
that?  
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>