Red Hat Bugzilla – Bug 169774
fence_wti status check fails
Last modified: 2009-04-16 16:27:44 EDT
Description of problem:
Problem with fence_wti
Version-Release number of selected component (if applicable):
After removing the network from one of the nodes, the other node is trying to
fence the failed node. This succeeds, after that the status of the fence is
checked and the following appears in messages file:
Sep 29 14:59:45 dbn42 fenced: fencing node "dbn41.mz.local"
Sep 29 14:59:48 dbn42 fenced: agent "fence_wti" reports: failed: plug not
Sep 29 14:59:48 dbn42 fenced: fence "dbn41.mz.local" failed
We already applied the change mentioned in bugzilla#162805. It looks like there
goes something wrong in the loop that checks the status of the ports (seems to
be running this loop only one time!). Only one line is of the status output is
analysed. We are using a WTI NPS-230.
Steps to Reproduce:
Status check of the port fails and keeps running in a loop. The failed cluster
resources are not brought online on the other node.
looking for hardware to test on.
Ryan - can you try and reproduce this, please? I have never been able to, with
the wti switch here in Westford...I don't know if you guys have this exact model
of WTI product in msp...
I'm attempting to reproduce this with a WTI NPS-115 that I have setup in the lab
here. It appears to be identical to the NPS-230 except that it is 115 VAC,
wheras the NPS-230 is 230 VAC.
I have not been able to reproduce this on an NPS-115, which should be identical
to the NPS-230 except for VAC (mentioned above).
Two things to mention:
1. The WTI NPS devices have a configurable "boot delay" which is used to set the
time between the off/on of a reboot operation. It seems possible that boot delay
could be set small enough that by the time we check the status (expecting "off")
we see that it is "on". However, I tried this with the lowest possible setting
(1 sec) and it did not occur. Even if this were the case, I would have expected
the log messages to suggest that is fould the state to be "ON". In the log
messages above, it appears the state is unknown.
2. There may be a very slight change in the console format due to different
firmware revisions. It appears that the switch I was testing with has version 2.00.
I am closing this since I am unable to reproduce this bug. If this continues to
be a problem, please reopen this bug with addition information, including the
firmware version, etc.