On Wed, Jun 08, 2005 at 11:47:06PM +0200, Sebastian Kayser wrote: > However all processes on the fenced node with access on the gfs volume > are blocked in a way i can't stop them (even with a SIGKILL), so i can't > umount the still "busy" gfs volume, and so i can't stop the cluster > daemons. All i am left with to regain access to the gfs volume is to > reboot the fenced node. > > The last message that gets written to syslog on the fenced node is > > Jun 8 21:29:05 sarge-fc2 kernel: GFS: fsid=cluster:gfs1.1: telling LM > to withdraw > > but that doesn't seem to have any effect. I also tried a 'gfs_tool > withdraw' to no avail. > > Is this behaviour by design (i.e. unkillable processes)? Is it possible > to avoid rebooting the node in order to regain gfs access? You're stuck with having to reboot the fenced node, we don't have any way to avoid that yet. The withdraw feature only applies to the case where gfs gets i/o errors but the node is still a fully functional member of the cluster. In that case the node will withdraw from the cluster, avoid being fenced, and gfs will let you unmount the fs. (Even in this case you should reboot the machine before doing anything else, though.) Dave -- Linux-cluster@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/linux-cluster
