At system start, bind9 fails to start on a recently created buster system. Some of the local bind is based on configuration from an earlier bind. The logs show /etc/bind/named.conf.options:2: change directory to '/var/cache/bind' failed: file not found
But if I then start it manually via systemctl, it starts. But then I need to fix up other services which were counting on working name resolution when they started. /var/cache/bind exists (at least right now, with bind running). Somewhat oddly it has a recent timestamp that coincided with a chron.hourly run, but not much other activity I see in the log. I started experiencing this problem when I activated the bind9-resolvconf service, though it's very simple and I don't see how it could matter. Internet search turned up https://serverfault.com/questions/404219/bind-9-8-not-loading-var-cache-bind-failed-file-not-found with the response "make the directory". Except I have the directory. Also, README.Debian says "The working directory for named is now /var/cache/bind." So it seems like something the package should have created on installation, or at least dynamically as it starts. Double-checked that apparmor seems to have entries that match. Unless the trailing slash is a problem? /var/cache/bind/** lrw, /var/cache/bind/ rw, That is, the program is trying to open /var/cache/bind, but the pattern is /var/cache/bind/. Of course, if it were an apparmor problem then my later restarts would have failed too, and they didn't. Some kind of race condition? The bind9 daemon is running as the bind user. Ideas? Thanks. Ross Boylan