On May 25, 2015, at 1:00 AM, Bob Proulx <b...@proulx.com> wrote: > Glenn English wrote: >> root@srv:~# ps -ef | grep named >> bind 2098 1 0 May10 ? 00:00:36 /usr/sbin/named -u bind >> root 10498 1 0 May10 ? 00:00:50 /usr/sbin/named -c >> /etc/bind/named.conf > > There are two of them running? That doesn't seem right. The first > one looks okay but the second one does not. > > I would be inclined to kill both of them. Then start it up again and > check all over again.
There are 3 servers involved, all running Wheezy, bind 9.8.4: srv, a Dell server box and the 'main' server for the domain -- dns (slave), email, web, ftp, ntp, imap, etc; ns2, the RaspberryPi secondary slave dns server; and log, the Supermicro server on the DMZ -- the only recursive DNS server, accessible only from the LAN and the slave DNS servers (it's called log because that's where things are logged). srv: Yesterday I killed and restarted the 2 bind processes and restarted the one owned by Bind. This morning, root's was back. But it seems to not be complaining about much today. I set the directory to mod 777 anyway. ns2: I found a possibly interesting thing in /var/cache: there's a 'bind' directory (owned by bind:bind) and a 'named' directory (owned by root:root). ns2 says it can't 'set file modification time' in /var/cache/bind of the slave info it gets from the master. A 'ls -lh' shows all the slave files were updated in the last few minutes, and are dated properly. There's no mention of the 'named' directory in the log, and it and all its files were created in 2013 anyway. I set both directories to mod 777 and the ownerships to bind:bind. log: This Bind has the same problem with setting the file modification time -- but only on its single slave file. I don't know if it modifies the master files. I don't see why Bind would be wanting to change the modification time anyway (NSD doesn't); the kernel does a pretty good job of that whenever a file is modified. There are 2 directories in log:/var/cache/bind: masters and slaves. I set /var/cache/bind and the two directories in it to mod 777. > Did you by any chance configure bind9 to run in a chroot? No. > The next thing I would wonder is if the 'immutable' bit were set on > the file system. Again from my system. > > $ lsattr -d /var/cache/bind > ---------------- /var/cache/bind All three are identical: root@ns2:/var/cache# lsattr -d /var/cache/bind -------------e-- /var/cache/bind > If all else fails I would be inclined to try an experiment. I would > open up the permissions on /var/cache/bind to be drwxrwxrwx and then > start bind9 and see what files it produces there. The owner and group > of the files produced should be a clue. They should be "bind" but if > they were something else that would explain the permission denied > message and be a clue as to the problem. > > service bind9 stop > chmod a+rwx /var/cache/bind > service bind9 start > ls -la /var/cache/bind Done on ns2. Can't set modification time and no tmp files in /var/cache/bind. Modification times look correct, though. On srv, no complaints in the log and no tmp files in the directory. I await with bated breath to see the logs, etc. tomorrow morning... -- Glenn English -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1f3aff71-02e5-4925-8c8f-06114a8ec...@slsware.net
