I am working now but I changed the script to hard code the location.
I added debug to it and I know my problem was the setting of the
IPMITOOL variable. It was not being set so I hard coded it and so far
so good I am alternating powering them off and I see the resources
switch next I will try the
Hi, Doug
Did you change this yourself to get it working or did your
distro/build include the scripts with $() instead of `` ?
No. I didn't change this, and I don't think it's the key.
Anyway, I should modify external/ipmi to enable logging, and try to
find the REAL return value when stonith
Hi, Doug
I tried Dejan's suggestion but I received the same result. Chun have
you had the cluster working and stonith _not_ complaining for a few
days and _then_ it started to complain about the 256 code? Or maybe
you are just now seeing that stonith is giving this message?
Some logs:
Feb 2
Did you change this yourself to get it working or did your
distro/build include the scripts with $() instead of `` ?
Yeah my eyes are going bad. I am so used to seeing ${...} It sucks
getting old :)
thanks,
Doug
On Fri, Feb 22, 2008 at 2:15 PM, Chun Tian (binghe)
<[EMAIL PROTECTED]> wrote:
>
Hi, there
I have verified that it is being run as root so I am a bit confused.
I also remember reading that the preferred way of doing command
expressions now in BASH is not with backticks but with ${} do I
substituted
IPMITOOL=`which ipmitool 2
Not ${} but $(), like this test:
[EMAIL PROTECT
I have verified that it is being run as root so I am a bit confused.
I also remember reading that the preferred way of doing command
expressions now in BASH is not with backticks but with ${} do I
substituted
IPMITOOL=`which ipmitool 2 wrote:
> Hi,
>
>
> On Fri, Feb 22, 2008 at 10:39:29AM -0500,
Hi,
On Fri, Feb 22, 2008 at 10:39:29AM -0500, Doug Lochart wrote:
> After hacking up the /usr/lib64/stonith/plugins/external/ipmi script
> I have discovered what is the problem. In the script the IPMITOOL
> shell variable is being set by `which ipmitool 2>/dev/null` command.
> This returns the p
After hacking up the /usr/lib64/stonith/plugins/external/ipmi script
I have discovered what is the problem. In the script the IPMITOOL
shell variable is being set by `which ipmitool 2>/dev/null` command.
This returns the proper location when run by a regular user or by
root. However I just check
I tried Dejan's suggestion but I received the same result. Chun have
you had the cluster working and stonith _not_ complaining for a few
days and _then_ it started to complain about the 256 code? Or maybe
you are just now seeing that stonith is giving this message?
I believe the problem may be h
Hi, there
I have tested stonith from the command line and was able to reset the
target PC. On the command I used the following:
stonith -t external/ipmi -T reset -p "capestor2 10.43.120.134 ADMIN
mypassword" capestor2
This worked marvelously! So then I move the stuff into the ha.cf.
Not hav
Hi,
On Thu, Feb 21, 2008 at 05:28:58PM -0500, Doug Lochart wrote:
> I have tested stonith from the command line and was able to reset the
> target PC. On the command I used the following:
>
> stonith -t external/ipmi -T reset -p "capestor2 10.43.120.134 ADMIN
> mypassword" capestor2
>
> This w
I have tested stonith from the command line and was able to reset the
target PC. On the command I used the following:
stonith -t external/ipmi -T reset -p "capestor2 10.43.120.134 ADMIN
mypassword" capestor2
This worked marvelously! So then I move the stuff into the ha.cf.
Not having much in t
12 matches
Mail list logo
