Bug 209476

Summary:	gam_server prevents correct service relocation in cluster suite failover
Product:	Red Hat Enterprise Linux 4	Reporter:	Nick Strugnell <nstrug>
Component:	gamin	Assignee:	Alexander Larsson <alexl>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.4	CC:	k.georgiou, tao
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-02-05 13:24:17 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 Nick Strugnell 2006-10-05 15:32:22 UTC

Description of problem:
If you ever use nautilus to delete a file in a filesystem that has been mounted
by RHCS, you will not be able to do a service relocation.

This is because a .Trash-<username> directory will be created and monitored by
gam_server

Clustersuite kills gam_server before unmounting, but gam_server immediately
respawns and therefore prevents clustersuite from unmounting the share.

Version-Release number of selected component (if applicable):
0.1.1-4.EL4

How reproducible:
always

Steps to Reproduce:
1. Use clusvcadm to start a service and mount a service partition
2. Use nautilus to delete a file in the service partition
3. Use clusvcadm to relocate the partition to another node
  
Actual results:
relocation fails with following in log:
Oct  5 15:48:29 clnode02 clurgmgrd: [7861]: <info> Executing
/etc/init.d/oractl.DEVFIN status
Oct  5 15:48:30 clnode02 clurgmgrd: [7861]: <info> unmounting /DEVCALM
Oct  5 15:48:30 clnode02 clurgmgrd: [7861]: <notice> Forcefully unmounting /DEVCALM
Oct  5 15:48:31 clnode02 clurgmgrd: [7861]: <warning> killing process 7093 (root
gam_serve /DEVCALM)
Oct  5 15:48:34 clnode02 clurgmgrd: [7861]: <crit> Could not clean up mountpoint
/DEVCALM
Oct  5 15:48:39 clnode02 clurgmgrd: [7861]: <info> Executing
/etc/init.d/oractl.DEVCLUB status
Oct  5 15:48:39 clnode02 clurgmgrd: [7861]: <info> Executing
/etc/init.d/oractl.PRODCLUB status
Oct  5 15:48:45 clnode02 clurgmgrd: [7861]: <info> unmounting /DEVCALM
Oct  5 15:48:45 clnode02 clurgmgrd: [7861]: <notice> Forcefully unmounting /DEVCALM
Oct  5 15:48:46 clnode02 clurgmgrd: [7861]: <warning> killing process 464 (root
gam_serve /DEVCALM)
Oct  5 15:48:49 clnode02 clurgmgrd: [7861]: <crit> Could not clean up mountpoint
/DEVCALM
Oct  5 15:48:49 clnode02 clurgmgrd: [7861]: <err> 'umount /DEVCALM' failed, error=0
Oct  5 15:48:49 clnode02 clurgmgrd[7861]: <notice> stop on fs "/DEVCALM"
returned 2 (invalid argument(s))
Oct  5 15:48:50 clnode02 clurgmgrd[7861]: <crit> #12: RG DEVCALM failed to stop;
intervention required
Oct  5 15:48:50 clnode02 clurgmgrd[7861]: <notice> Service DEVCALM is failed
Oct  5 15:48:52 clnode02 clurgmgrd[7861]: <alert> #2: Service DEVCALM returned
failure code.  Last Owner: clnode02-heartbeat
Oct  5 15:48:52 clnode02 clurgmgrd[7861]: <alert> #4: Administrator intervention
required.


Expected results:
relocation works

Additional info:
I've filed this in RHEL rather than in RHCS as it seems to me that RHCS would
have no way of knowing or preventing this behaviour. However, you may wish to
liaise with cluster-team in coming up with a fix.

Workaround:
Workaround is to delete the Trash folders and restart gam_server and ensure that
you do not use the graphical filemanager in the RHCS-managed filesystems.

Comment 1 Alexander Larsson 2006-10-06 07:26:45 UTC

Another fix is to set up gamin to use polling for the specific mount
http://www.gnome.org/~veillard/gamin/config.html

If you unmount from nautilus itself it will unmonitor the directory itself, but
there is really no way to know that something else will be unmounting a
filesystem. In later kernel versions the inotify support is used by gamin
instead of dnotify, which doesn't keep the mountpoint open, however there is no
inotify support in RHEL4.

I can't see any way to fix this.