Red Hat Bugzilla – Bug 431061
new NFS Client resource causes service to fail
Last modified: 2010-10-22 18:11:59 EDT
Description of problem:
Version-Release number of selected component (if applicable):
How reproducible: always
Steps to Reproduce:
1. Create a cluster configuration that contains an NFS Export resource
2. Activate the cluster configuration and activate the service that contains the
NFS Export resource. Make sure it's running ok.
3. In s-c-c, open the Service Management window for the service that contains
the NFS Export resource.
4. Click select the NFS Export resource it in the Service Resource List
5. Click "Attach a new Private Resource to the Selection"
6. Create a new NFS Client resource, leave the Path field blank
7. Click OK and Close to close the open dialogs and send the new configuration
to the cluster
rgmanager will try to restart the service, but it will fail:
Jan 31 09:08:07 el4 clurgmgrd: <info> Starting changed resources.
Jan 31 09:08:07 el4 clurgmgrd: : <err> No export path specified.
Jan 31 09:08:07 el4 clurgmgrd: <notice> start on nfsclient:el52 returned
2 (invalid argument(s))
rgmanager should be able to restart the service without any problem.
The problem is caused by the empty path="" attribute that gets inserted into the
new nfsclient element. This can be verified by removing that attribute and
A workaround is the following: after Step 6. to create the new private resource,
click it in the Service Resource List, Edit it, save it. Editing it will make
the empty path="" attribute go away.
Created attachment 294003 [details]
It seems that the patch we prepared fixes the problem.
Thanks for the patch - will have this fix checked in today.
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.
This fix does not appear to have made it into system-config-cluster-1.0.54-2.0.
Indeed. Yet, I attempted to use the steps to reproduce the problem and the path="" element is not there in the config file, so this was probably fixed in a different way.