Anybody know how to debug things like this?

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > The only safe alternative would be to force the initial DNS lookups to be
> > synchronous. 
> 
> That doesn't work for the pool case.  It wants to get more servers if some of 
> the ones it is using stop responding.

Noted.

> > A: get configuration (that's the early thread launch)
> 
> We could split the DNS lookups out of that.  It would add a new step to your 
> list.
> 
> > E. initializing = false
> > Moving F and B is no problem, but the others worry me - especially the
> > setting of initialize, which does things I don't understand to the protocol
> > machine.  My spider sense is tingling.
> 
> The DNS lookups may take a long time, so starting them a bit later should be 
> OK.
> 
> It wouldn't surprise me if we discovered problems.  That's a mixed blessing.  
> Finding problems is always good, but we would also have to to fix them.
> 
> --------
> 
> I've found 2 more quirks associated with early sandbox.
> 
> The PID file needs to be writable by ntp.  That should be easy to fix - just 
> some scripting before starting ntpd.  systemd doesn't have that scripting, 
> but it doesn't use a pid file.
> 
> The other is that NetBSD won't let ntp open wildcard sockets.  It may be 
> sockets with port# less that 1024.  I don't have a solution but I haven't 
> looked very hard.

I'm in favor of cleaning up and fixing some of these order
dependencies, but I'd rather get us to a safe and functioning state
first.  Accordingly, splitting out seccomp() implementation to do it
early and keeping droproot late is looking better and better.

In some sense this is my error.  I think it used to work as above until
I created sandbox() to hide all the ugly platform-dependent privilege
containment stuff in.

I just managed one relevant refactor.  The "initializing" global is gone.
That will simplify later changes a lot.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>