There are two problems here. First is that the bind9.postinst fails to
set permissions correctly in some circumstances, and second that without
the permissions set correctly, you get 100% CPU usage.
The 100% CPU usage problem is already in bug 1038199, so we can track
that there. That leaves this
Robie,
No problem - I'm just glad I wasn't imagining it.
I agree the 100% CPU problem can't be reproduced on precise.
To be honest I don't quite understand why /var/cache/bind isn't in
/var/run (given it's a cache) but I may be wrong about that.
Alex
--
You received this bug notification beca
Thanks for your insight Alex. I've managed to reproduce this now, with
the following steps:
On Lucid:
1. sudo apt-get install bind9
2. sudo apt-get remove bind9
# this removes /var/cache/bind but leaves /etc/bind9/rndc.key
3. sudo apt-get install bind9
# Now the postinst doesn't fix /var/cach
To follow this up, the .deb at least on Lucid does NOT have the write
permission set.
amb@nimrod-ubuntu:~/bind-test$ dpkg -c bind9_9.7.0.dfsg.P1-1ubuntu0.8_amd64.deb
| fgrep cache
drwxr-xr-x root/root 0 2012-10-09 14:13 ./var/cache/
drwxr-xr-x root/root 0 2012-10-09 14:13 ./var/ca
OK so my working hypothesis is this. On Lucid /var/cache/bind is created
simply by virtue of it being a directory within the package (see the
bind9.list file). The group write permission is added by the postinst.
If the Lucid package was installed, then removed, then installed again,
the following
On Wed, Dec 05, 2012 at 05:48:18PM -, Alex Bligh wrote:
> See rndc.key is owned by UID 103, which is not equal to 0. So the
> Precise postinst script does not do the chmod.
This is what I would expect, because the permissions on /var/cache/bind
should already be correct, and maintainer scripts
Well I'm pretty sure the problem is this. I've just gone to another
(unconnected) Lucid box, and:
root@extility-developers:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 10.04.4 LTS
Release:10.04
Codename: lucid
root@extility-developers:
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 roo
The server concerns was automatically installed from a CD-ROM built from
Ubuntu sources and (in respect of bind) it has only had automatic
updates run on it. I am very confident it was not operator error.
It was upgraded with 'do-release-upgrade'.
I can tell you I am not the only person experienc
Thank you for taking the time to report this bug and helping to make
Ubuntu better.
I've not been able to reproduce this when upgrading from Lucid to
Precise (1:9.7.0.dfsg.P1-1ubuntu0.8 to 1:9.8.1.dfsg.P1-4ubuntu0.4).
/var/cache/bind had the correct (775) permissions. If I remove its
contents and
** Description changed:
Summary: bind9 uses very high CPU after an upgrade from Lucid to
Precise. I have traced this to a directory permissions problem as
/var/cache/bind is not writeable by the bind group after an upgrade, but
is writeable after a clean install.
Ubuntu release:
roo
11 matches
Mail list logo
