With as many users as we have, a common misconfiguration can lead to a number of reports. I'd have expected dozens of reports or more by now if this were a systemic upgrade problem. Also note that one of the reports you linked to has root group ownership too, which is inconsistent with a single root cause.
I've looked at the ways the bind9 maintainer scripts call chmod, and don't see how a group write permission could get lost: $ grep chmod /var/lib/dpkg/info/*bind* /var/lib/dpkg/info/bind9.postinst: chmod 775 /var/lib/bind /var/lib/dpkg/info/bind9.postinst: chmod g+s /etc/bind /var/lib/dpkg/info/bind9.postinst: chmod g+r /etc/bind/rndc.key /etc/bind/named.conf* || true /var/lib/dpkg/info/bind9.postinst: chmod g+rwx /var/run/named /var/cache/bind I've checked the maintainer scripts this way across Hardy, Lucid and Precise. It looks to me that the existing postinst intentionally avoids doing the chmod except in a particular circumstance which I presume is for upgrading from a specific previous version (presumably prior to Hardy). I'd like to understand the root cause before I'm comfortable pushing to change this, and there is a trivial workaround for those affected. So steps to reproduce the problem would really help! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1086775 Title: bind9 uses high CPU after lucid->precise upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1086775/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
