On 6/18/07, Junko IKEDA <[EMAIL PROTECTED]> wrote:
Here is the result.
I found the following message in ha-debug.
cancel_monitor: Couldn't cancel prmDummy1_monitor_10000 (4): -1

Is there something wrong about my configuration?

no, its related to a recent lrm change where cancel operations are no
longer syncronous

the crmd hasn't caught up with this change yet


Thanks,
Junko

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Beekhof
> Sent: Monday, June 18, 2007 8:27 PM
> To: General Linux-HA mailing list
> Subject: Re: [Linux-HA] failcount is up despite "is_managed" is false
>
> On 6/18/07, Junko IKEDA <[EMAIL PROTECTED]> wrote:
> > Andrew,
> > Thank you. It worked.
> > But when I set "disable" back to 'false', monitor didn't re-start.
>
> odd, it should do
>
> can you attach the result of "cibadmin -Ql" please?
>
> > Should I stop/start the resource?
> >
> > Thanks,
> > Junko
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Andrew
Beekhof
> > > Sent: Monday, June 18, 2007 7:49 PM
> > > To: General Linux-HA mailing list
> > > Subject: Re: [Linux-HA] failcount is up despite "is_managed" is false
> > >
> > > On 6/18/07, Junko IKEDA <[EMAIL PROTECTED]> wrote:
> > > > I see...
> > > > Is there any way to just stop monitor action? (only monitor)
> > >
> > > "op" objects have the "disabled" field for that:
> > >           disabled      (true|1|false|0)               'false'
> > >
> > > set disabled=true and the monitor will be stopped.
> > >
> > > > It's better if monitor could re-start after that.
> > > >
> > > > I tried this.
> > > > (this ended up in failure, it might be illegal for OCF rule)
> > > >
> > > > 1) remove monitor action from cib.
> > > >       cibadmin -D <op id="opmon" name="monitor" interval="10s"
> > > timeout="10s"
> > > > />
> > > >    monitor seems to be stopped.
> > > >
> > > > 2) add monitor action to cib.
> > > >       cibadmin -U \
> > > >       <primitive id="Dummy1" class="ocf" type="Dummy"
> > > provider="heartbeat">
> > > > \
> > > >       <operations> \
> > > >       <op id="opmon" name="monitor" interval="10s" timeout="10s"/> \
> > > >       </operations> \
> > > >       </primitive>
> > > >     monitor doesn't restart.
> > > >
> > > >
> > > > Thanks,
> > > > Junko
> > > >
> > > > > -----Original Message-----
> > > > > From: Max Hofer [mailto:[EMAIL PROTECTED]
> > > > > Sent: Monday, June 18, 2007 3:32 PM
> > > > > To: [email protected]
> > > > > Cc: Junko IKEDA
> > > > > Subject: Re: [Linux-HA] failcount is up despite "is_managed" is
false
> > > > >
> > > > > If i remember correctly the resource is still monitored, even
> > > > > if you set is_managed to false. This is needed because other
> > > > > resource may depend on the unmanagened resource.
> > > > >
> > > > > is_managed false ---> this resource is not started/stopped by the
> > > > > cluster manager (but not "this resource is not monitored
anymore").
> > > > >
> > > > > On Monday 18 June 2007, Junko IKEDA wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I got the newest dev version, and tried to change a resource
> > parameter
> > > > with
> > > > > > crm_resouces including --meta option.
> > > > > > What I wanted to change is 'is_managed' parameter.
> > > > > > I could change it with --meta successfully, but there was
something
> > > > wrong.
> > > > > > After changing is_managed to false, I forced the resource to
stop,
> > > > > > (in this case, remove /var/run/heartbeat/rsctmp/Dummy.state)
> > > > > > the failcount of this resource was up.
> > > > > >
> > > > > > Is it expected?
> > > > > > I expected that if is_managed was false, heartbeat wouldn't
manage
> > its
> > > > > > resource status; ex.) stop or fail;
> > > > > >
> > > > > >
> > > > > > Best Regards,
> > > > > > Junko Ikeda
> > > > > >
> > > > > > NTT DATA INTELLILINK CORPORATION
> > > > > > Open Source Solutions Business Unit
> > > > > > Open Source Business Division
> > > > > >
> > > > > > Toyosu Center Building Annex, 3-3-9, Toyosu,
> > > > > > Koto-ku, Tokyo 135-0061, Japan
> > > > > > TEL : +81-3-3534-4810
> > > > > > FAX : +81-3-3534-4814
> > > > > > mailto:[EMAIL PROTECTED]
> > > > > > http://www.intellilink.co.jp/
> > > > > >
> > > > > > _______________________________________________
> > > > > > Linux-HA mailing list
> > > > > > [email protected]
> > > > > > http://lists.linux-ha.org/mailman/listinfo/linux-ha
> > > > > > See also: http://linux-ha.org/ReportingProblems
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Max Hofer
> > > > > APUS Software G.m.b.H.
> > > > > A-8074 Raaba, Bahnhofstraße 1/1
> > > > > T| +43 316 401629 11
> > > > > F| +43 316 401629 9
> > > > > W| www.apus.co.at
> > > > > E| [EMAIL PROTECTED]
> > > >
> > > > _______________________________________________
> > > > Linux-HA mailing list
> > > > [email protected]
> > > > http://lists.linux-ha.org/mailman/listinfo/linux-ha
> > > > See also: http://linux-ha.org/ReportingProblems
> > > >
> > > _______________________________________________
> > > Linux-HA mailing list
> > > [email protected]
> > > http://lists.linux-ha.org/mailman/listinfo/linux-ha
> > > See also: http://linux-ha.org/ReportingProblems
> >
> > _______________________________________________
> > Linux-HA mailing list
> > [email protected]
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha
> > See also: http://linux-ha.org/ReportingProblems
> >
> _______________________________________________
> Linux-HA mailing list
> [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to