Bug 162824 - Shared nfsclient references by multiple filesystems don't get monitored
Summary: Shared nfsclient references by multiple filesystems don't get monitored
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Cluster Suite
Classification: Retired
Component: rgmanager
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Lon Hohberger
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-07-08 22:34 UTC by Eric Kerin
Modified: 2009-04-16 20:17 UTC (History)
1 user (show)

Fixed In Version: RHBA-2005-738
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-07 16:52:14 UTC
Embargoed:


Attachments (Terms of Use)
Proposed fix (4.03 KB, patch)
2005-07-08 22:40 UTC, Eric Kerin
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:738 0 normal SHIPPED_LIVE rgmanager bug fix update 2005-10-07 04:00:00 UTC

Description Eric Kerin 2005-07-08 22:34:04 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1

Description of problem:
Shared nfsclient resources do not get status monitor run against them if they are referenced multiple times.   This was originally posted by Birger Wathne on the linux-cluster mailing list.

In the config file below, only 5 of the 9 exports below get a status monitor, export1fs:h-nfs-root
export1fs:h-nfs-insecure-ro
export1fs:nis-hosts-ro
export2fs:h-nfs-insecure
export2fs:nis-hosts

The rest do not get checked since they are the second reference to the shared resource.


Relevant cluster.conf section---
       <resources>
    <fs fstype="ext3" name="export1fs" mountpoint="/exports/export1" device="/dev/LocalGroup01/Export1Vol00" options="acl"/>
    <fs fstype="ext3" name="export2fs" mountpoint="/exports/export2" device="/dev/LocalGroup01/Export2Vol00" options="acl"/>
    <fs fstype="ext3" name="export3fs" mountpoint="/exports/export3" device="/dev/LocalGroup01/Export3Vol00" options="acl"/>

    <nfsclient name="nis-hosts" target="172.19.30.31" options="rw,sync"/>
    <nfsclient name="nis-hosts-ro" target="172.19.30.32" options="ro,sync,no_root_squash"/>
    <nfsclient name="h-nfs-root" target="172.19.30.33" options="rw,sync,no_root_squash"/>
    <nfsclient name="h-nfs-insecure" target="172.19.30.34" options="rw,sync,insecure"/>
    <nfsclient name="h-nfs-insecure-ro" target="172.19.30.35" options="ro,sync,no_root_squash,insecure"/>
  </resources>

  <service name="nfssvc">
    <fs ref="export1fs">
      <nfsexport name="export1fs">
        <nfsclient ref="h-nfs-root"/>
        <nfsclient ref="h-nfs-insecure-ro"/>
        <nfsclient ref="nis-hosts-ro"/>
      </nfsexport>
    </fs>
    <fs ref="export2fs">
      <nfsexport name="export2fs">
        <nfsclient ref="h-nfs-root"/>
        <nfsclient ref="h-nfs-insecure"/>
        <nfsclient ref="nis-hosts"/>
      </nfsexport>
    </fs>
    <fs ref="export3fs">
      <nfsexport name="export3fs">
        <nfsclient ref="h-nfs-root"/>
        <nfsclient ref="h-nfs-insecure"/>
        <nfsclient ref="nis-hosts"/>
      </nfsexport>
    </fs>
  </service>


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Reference the same nfsclient shared resource in multiple filesystem nfsexport


  

Actual Results:  only 5 monitor commands are executed, instead of 9.

Expected Results:  All 9 exports are monitored.

Additional info:

Comment 1 Eric Kerin 2005-07-08 22:40:01 UTC
Created attachment 116552 [details]
Proposed fix

The proposed patch makes a copy of the resource action list in each resource
node that references a resource.  It then uses that list when checking the
status, so each use of the resource has it's own last checked timestamp for
each action.

Comment 3 Eric Kerin 2005-07-12 05:17:18 UTC
I received an email from Birger, stating that the patch did fix the nfs export
monitoring problem on his cluster.

Comment 4 Lon Hohberger 2005-07-12 14:58:39 UTC
Excellent.  Putting in STABLE, RHEL4, and HEAD.


Comment 5 Lon Hohberger 2005-07-12 15:27:39 UTC
I ran a regression test to ensure that there was no memory leaked; there wasn't.
 Patch is definitely acceptable.

Comment 6 Lon Hohberger 2005-07-12 15:35:07 UTC
Patches in.

Comment 8 Red Hat Bugzilla 2005-10-07 16:52:14 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 the 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-2005-738.html



Note You need to log in before you can comment on or make changes to this bug.