Bug 526286

Summary:	Cluster FS resource doesn't ignore bind mounts during status check
Product:	Red Hat Enterprise Linux 5	Reporter:	Eric Johnson <eric.johnson>
Component:	rgmanager	Assignee:	Lon Hohberger <lhh>
Status:	CLOSED ERRATA	QA Contact:	Cluster QE <mspqa-list>
Severity:	medium	Docs Contact:
Priority:	low
Version:	5.4	CC:	cluster-maint, edamato
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	rgmanager-2.0.52-1.35.el5	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-03-30 08:49:37 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Eric Johnson 2009-09-29 16:32:36 UTC

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.

Comment 1 Lon Hohberger 2009-12-14 22:47:26 UTC

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.

Comment 2 Lon Hohberger 2009-12-15 16:31:58 UTC

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.

Comment 3 Lon Hohberger 2009-12-15 16:38:05 UTC

http://git.fedorahosted.org/git/?p=cluster.git;a=commit;h=b5be828615a2ed7bd95a3796d96f5cc536e2adc7

Comment 5 Lon Hohberger 2009-12-21 18:32:00 UTC

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

Comment 10 errata-xmlrpc 2010-03-30 08:49:37 UTC

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