Fabio M. Di Nitto wrote: > On Thu, 2009-02-26 at 08:33 -0600, David Teigland wrote: >> On Thu, Feb 26, 2009 at 07:51:57AM +0100, Fabio M. Di Nitto wrote: >>> On Mon, 2009-02-23 at 13:09 -0600, David Teigland wrote: >>>> On Mon, Feb 23, 2009 at 07:52:55PM +0100, Fabio M. Di Nitto wrote: >>>>>> A node unfences *itself* when it boots up. As such, power-unfencing >>>>>> doesn't >>>>>> make sense; unfencing is only meant to reverse storage fencing. >>>>> What can stop a user to run fence_node -U from another node to do remote >>>>> (un)fencing? >>>> It would work. Users can do anything they like, that's beside the point. >>> I was thinking about 2 little points.. >>> >>> Given the time at which fence_node -U will fire, you probably want to >>> add a cman_init + cman_is_active + cman_finish loop in fence_node to >>> make sure cman is ready to reply to our ccs queries, otherwise we might >>> have a race condition at boot time (it might be already there.. didn't >>> really check the code). All our daemons do that to give cman time to >>> bootstrap. >> Yes, good point. I wonder if we'd be better off having cman_tool join >> effectively do an is_active wait before exiting? Then we could probably >> avoid doing it many other places. (It's also annoying when corosync crashes >> after is_active completes, but before I've read what I need from cman/ccs.) >
Err, cman_tool already does this with the -w switch, and the init script uses it. > hmm.. it might be reasonable to ask cman_tool to do that, b Chrissie
