On 16, May, 2005, David Teigland declared: > On Mon, May 16, 2005 at 02:19:23AM -0400, Dan B. Phung wrote: > > In the usage of our cluster, we have machines getting rebooted often, > > which causes gfs to hang in waiting for the fence_ack_manual. Usually I'm > > sure the rebooting node(s) fenced, so I find the manual acking redundant. > > I could also use the fence_sanbox2 fenced, but I don't like the idea of > > having to enable the switch ports before the node can reenter the cluster. > > If you're doing controlled reboots, you should have the node > shutdown/leave the cluster cleanly. Then it won't be fenced. we're doing some kernel hacking and the module we're loading currently doesn't unload (i know, it's stupid...). The module uses the mounted file systems, thus cman_tool can't unregister because there are still some active subsystems. this is the reason for the node being fenced. > If that's not possible, you can have a node automatically re-enable its > own switch port when it starts up by calling 'fence_sanbox2 -o enable' > directly. ah, cool. but wouldn't the cluster be "hung" while it waits for the node to come back up? > > > I was thinking of "hacking" the daemon on my stable master node so that it > > sends the fence ack as soon as it's requested. Does something like my > > usage scenario already exist? > > no > > > Does this violate some principal design in the fenced? > > Yes, it's equivalant to doing no fencing at all. :) again, i'm misusing your wonderful software! -dan -- -- Linux-cluster@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/linux-cluster
