Bug 162824 - Shared nfsclient references by multiple filesystems don't get monitored
Shared nfsclient references by multiple filesystems don't get monitored
Status: CLOSED ERRATA
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: rgmanager (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Lon Hohberger
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-08 18:34 EDT by Eric Kerin
Modified: 2009-04-16 16:17 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2005-738
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-07 12:52:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Eric Kerin 2005-07-08 18:34:04 EDT
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 18:40:01 EDT
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 01:17:18 EDT
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 10:58:39 EDT
Excellent.  Putting in STABLE, RHEL4, and HEAD.
Comment 5 Lon Hohberger 2005-07-12 11:27:39 EDT
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 11:35:07 EDT
Patches in.
Comment 8 Red Hat Bugzilla 2005-10-07 12:52:14 EDT
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.