The problem start with a message No space left on device. After investigating a little (with google's help) I found :
find: File system loop detected; /var/named/chroot/var/named' is part of the same file system loop as/var/named'.
What I don't know is what to do next. I found this on centos.org :
and see if the inode numbers are the same (they shouldn't be). If they are then you need to remove the /var/named/chroot/var/named/ hard link and recreate it as a directory
the inode number are the same but I don't know exactly which folder to delete and what to do next
thank you for any help
Linux xxxxx.onlinehome-server.info 2.6.32-220.13.1.el6.x86_64 #1 SMP Tue Apr 17 23:56:34 BST 2012 x86_64 x86_64 x86_64 GNU/Linux
Best Answer
If this was part of an intentional bind-chroot install, (I believe) when you remove the directory and recreate it, the inode numbers will of course then be different. However, once you restart the named service it's init script will once again mount --bind /var/named to var/named/chroot/var/named and you will logically once again see identical inode numbers.
I have wasted some time trying to figure out whether or not this is normal, with the added confusion that some past fool at my site thought some custom init scripts would be a good idea, so I really don't know what's normal anymore.
Apparently, this may be standard behavior on centos with bind-chroot, but I find it hard to believe, because anything that leads to something like:
grep -r something /var/named
grep: memory exhausted
(on an R610 with 16GB of RAM)
has got to be one of the dumbest things I've seen in a long time.
Anyone know if this is stock behavior for bind-chroot? If so, I'd have to say stay away from it on redhat/centos. i will certainly never recommend these distros to anyone serious about doing things in a non-ridiculous way.