Description of problem: On an NFSv4 cluster that uses bind mounts to arrange cluster controlled file systems in the NFS root, this causes consistent warnings from clurgmgrd: Sep 28 14:33:12 node1 clurgmgrd: [4150]: <warning> Device /dev/nfsvg/fs1lv is mounted on /nfsroot/fs1 instead of /fs1 Sep 28 14:33:12 node1 clurgmgrd: [4150]: <warning> Device /dev/nfsvg/fs2lv is mounted on /nfsroot/fs2 instead of /fs2 Sep 28 14:33:12 node1 clurgmgrd: [4150]: <warning> Device /dev/nfsvg/fs3lv is mounted on /nfsroot/fs3 instead of /fs3 Version-Release number of selected component (if applicable): RHEL 5.4 x86 rgmanager-2.0.52-1.el5 cman-2.0.115-1.el5_4.2 openais-0.80.6-8.el5 kernel-2.6.18-164.el5 How reproducible: Every time Steps to Reproduce: 1. Create an ext3 file system resource in the cluster config, assign to a service and activate that service. 2. Create a bind mount that makes that file system available somewhere else in the directory hierarchy. Actual results: Clurgmgrd will start complaining into /var/log/messages that the file system is mounted in a location that differs from the cluster configuration. Expected results: The fs resource script should ignore the bind mount. No warnings should be generated in this case. Additional info: Cluster script fs.sh doesn't exclude bind mounts in the isMounted() function. The /proc/mounts source it uses to determine mount points doesn't provide sufficient information to distinguish a real mount point from a bind mount point.
The way bind mounts work is actually more accurately reflected in /proc/mounts than in /etc/mtab (or the output of the 'mount' command). For example: mount -t ext3 /dev/sdb3 /foo mount -o bind /foo /mnt/tmp umount /foo ... the output of 'mtab' is nonsensical: you have something for which you have no record (/foo) now bind-mounted on /mnt/tmp. Consequently, the only solution to this problem without causing very strange behavior in some cases is to simply remove the warning message.
Actually, here's a more correct fix: - check all mounts - if we are mounted in the right place, return success - if not, log a warning w/ the last-read (incorrect) mount point This will catch the case where an administrator umounts the original mount point but has other locations bind-mounted. The side effect is that only one bind mount will be logged per incident.
http://git.fedorahosted.org/git/?p=cluster.git;a=commit;h=b5be828615a2ed7bd95a3796d96f5cc536e2adc7
The 'start' phase was producing an incorrect warning as a result of the previous patch; this fixes it. http://git.fedorahosted.org/git/?p=cluster.git;a=commit;h=8d523d56d6d36b7b84ebafb923908a3a79b72938
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0280.html