I have another data point to contribute, courtesy of DTE - our local power company - and a power outage that lasted longer than my UPS battery...
First, the problem still exists with bind9 9.16.4-1+b1. Second (and most interestingly), this version WILL start successfully if you are upgrading from an earlier version (such as /stable) and do not reboot. The sequence of events: 1. Feeling bored, I try upgrading bind9 and friends to current /testing version 2. I check carefully and see the upgrade was unexceptional and the new named daemon started without problems 3. Subsequently, we take a power hit that results in a normal system shutdown (when UPS reached critical level) and normal system boot (after power was restored) 4. named failed to start at boot time, as described previously in this problem 5. named failed to start manually too 6. I downgraded bind9 to /stable, and (of course) named started normally 7. I upgraded bind9 to /testing 8. something got confused at this point, and the old named was still running (I could tell by the start time) 9. I manually killed the named process 10. "systemctl start named" successfully started the new named I verified in /var/log/daemon.log that the running daemon is identifying itself as: Aug 22 23:14:35 buzz named[151367]: starting BIND 9.16.4-Debian (Stable Release) <id:0849b42> I still have no idea exactly what initialization is missing, but it's clear that the /stable named is doing it but the /testing named is not. Why nobody else seems to be seeing this problem is yet another interesting question. There have been no configuration file changes since my initial problem report. Puzzled, Scott
