2 errors with last install : df and csf

Though of course you won't be able to unmount root partition on a running server, try this:

Code:
cat /proc/mounts  | grep /var/named/chroot/ | awk '{system("echo "$2)}'

and this

Code:
cat /proc/mounts  | grep /var/named/chroot/ | awk '{system("umount "$2)}'
 
This is now better !

Code:
# cat /proc/mounts  | grep /var/named/chroot/ | awk '{system("umount "$2)}'
sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `umount /var/named/chroot/etc/named.conf\040(deleted)'

Code:
# df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                 34G  6.7G   26G  21% /
/dev/root              34G  6.7G   26G  21% /
none                   16G  452K   16G   1% /dev
/dev/md3              1.8T  505G  1.2T  30% /home
tmpfs                  16G  4.0K   16G   1% /dev/shm
df: `/var/named/chroot/etc/named.conf (deleted)': No such file or directory
/dev/loop0           1008M  220M  737M  23% /tmp

Thanks for your helping messages
 
The first of these links says specifically that the file should never be written to, and the latter mentions no reason to ever write to it. I stand by my point. The entire purpose of the file is to tell the admin what's mounted and how.

Jeff
 
Switching a production server to a software RAID is one of the possible examples: http://www.howtoforge.com/software-raid1-grub-boot-debian-etch-p2
While I'd call that a special case, note that the only reason to do it is still to allow admins to know the file structure has been changed if mounting and unmounting during the installation doesn't change it for you. It's still not read by any system function, and it will be rewritten when the system is restarted.

To verify, reboot a server and look at the datestamp on the /etc/mtab file.

Jeff
 
I can only wonder if somehow bind-chroot is actually mounting some kind of phantom partition. I doubt it, but I'd certainly like to try to unmount them to see.

And I'm curious; if you mount in single mode (single-user mode, repair or maintenance mode) do they still get mounted?

If the mounts aren't happening from fstab, then they shoulkd be in one of the scripts called during the startup scripts; start looking through the rc.d directories and the rc.init directory, both with and without bind-chroot installed.

Jeff
 
umount /var/named/chroot/etc/named.conf

Yes it works.
Thanks, now, I have no more error with df -h
 
If the mounts aren't happening from fstab, then they shoulkd be in one of the scripts called during the startup scripts; start looking through the rc.d directories and the rc.init directory, both with and without bind-chroot installed.


The user pppplus has already removed bind-chroot from the system.

Here is my investigation of the issue:

The init script /etc/init.d/named from rpm for CentOS 5 does not have anything like that (at least in my particular case):

Code:
[root@dns /]# rpm -qa | grep bind
bind-libs-9.3.6-20.P1.el5_8.6
bind-9.3.6-20.P1.el5_8.6
bind-utils-9.3.6-20.P1.el5_8.6
bind-chroot-9.3.6-20.P1.el5_8.6

[root@dns /]# ps aux | grep named
named     7370  0.2  1.3 252216  6880 ?        Ssl  14:21   0:00 /usr/sbin/named -u named -4 -u named -t /var/named/chroot
root      7426  0.0  0.1   6132   616 pts/1    S+   14:22   0:00 grep named

[root@dns /]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/simfs             20G  1.3G   19G   7% /
/dev/simfs             20G  1.3G   19G   7% /var/named/chroot/var/run/dbus


Of course it might differ on CentOS 6. So I went on investigating:

pppplus said:
I have centos 6-64 bits

for
pppplus said:
bind-chroot.x86_64 32:9.8.2-0.10.rc1.el6_3.6

Though the package does not have any init script in itself:

Code:
Content of RPM :
/var/named/chroot
 /var/named/chroot/dev
 /var/named/chroot/dev/null
 /var/named/chroot/dev/random
 /var/named/chroot/dev/zero
 /var/named/chroot/etc
 /var/named/chroot/etc/localtime
 /var/named/chroot/etc/named
 /var/named/chroot/etc/named.conf
 /var/named/chroot/etc/pki
 /var/named/chroot/etc/pki/dnssec-keys
 /var/named/chroot/usr
 /var/named/chroot/usr/lib64
 /var/named/chroot/usr/lib64/bind
 /var/named/chroot/var
 /var/named/chroot/var/log
 /var/named/chroot/var/named
 /var/named/chroot/var/run
 /var/named/chroot/var/run/named
/var/named/chroot/var/tmp

http://rpm.pbone.net/index.php3/sta...chroot-9.8.2-0.10.rc1.el6_3.6.x86_64.rpm.html

And the package bind-9.8.2-0.10.rc1.el6_3.6.x86_64.rpm does contain an init script which has the following function:

Code:
mount_chroot_conf()
{
  if [ -n "$ROOTDIR" ]; then
    for all in $ROOTDIR_MOUNT; do
      # Skip nonexistant files
      [ -e "$all" ] || continue

      # If mount source is a file
      if ! [ -d "$all" ]; then
        # mount it only if it is not present in chroot or it is empty
        if ! [ -e "$ROOTDIR$all" ] || [ `stat -c'%s' "$ROOTDIR$all"` -eq 0 ]; then
          touch "$ROOTDIR$all"
          mount --bind "$all" "$ROOTDIR$all"
        fi
      else
        # Mount source is a directory. Mount it only if directory in chroot is
        # empty.
        if [ -e "$all" ] && [ `ls -1A $ROOTDIR$all | wc -l` -eq 0 ]; then
          mount --bind "$all" "$ROOTDIR$all"
        fi
      fi
    done
  fi
}

for mounting those things. And this function:

Code:
umount_chroot_conf()
{
  if [ -n "$ROOTDIR" ]; then
    for all in $ROOTDIR_MOUNT; do
      # Check if file is mount target. Do not use /proc/mounts because detecting
      # of modified mounted files can fail.
      if mount | grep -q '.* on '"$ROOTDIR$all"' .*'; then
        umount "$ROOTDIR$all"
        # Remove temporary created files
        [ -f "$all" ] && rm -f "$ROOTDIR$all"
      fi
    done
  fi
}

for unmounting.

Thus, to solve the issue, the TS probably should had to restart or stop the named and then only remove bind-chroot package from system.
 
Last edited:
Thanks for your investigation, Alex. It helps us all understand the problem.

Jeff
 
Just for information, I mount a new server, with centos 6 64 bits, and same problems.
So, I suppose it's something in default centos 6 (but maybe it's ovh installation doing this)

Your solution will probably help other persons

And : yum remove bind-chroot
+ reboot

And problem is solved.
 
Last edited:
but maybe it's ovh installation doing this

OVH does not allow a default installation of CentOS be default. They give their images with CentOS which is based on their customized kernel. Don't they? So I'd rather say the issue is related to OVH.
 
That could well be the case Alex.
We also have a Centos 6 server from OVH and bind-chroot was installed there by default. However I did not see any problems, probably because I always first remove most unneeded packages before I start the DA installation.
So removing bind-chroot was one of the first things I did.
 
Back
Top