[Pacemaker] "probe" operations always use cluster default operation timeout

Tim Serong tserong at novell.com
Wed Nov 17 21:33:23 EST 2010

Hi Ron,

On 11/18/2010 at 11:26 AM, Ron Kerry <rkerry at sgi.com> wrote: 
> I have noted a problem that exists in both SLE11-HAE and SLE11-HAE-SP1  
> distributions with the  
> "probe" operation that takes place when openais is first started on a node  
> to determine whether a  
> resource is actively running or not. 
> Nov 17 17:47:07 gto2 lrmd: [13475]: debug: on_msg_perform_op: add an  
> operation operation monitor[2] 
>    on ocf::cxfs::CXFS for client 13478, its parameters:  
> crm_feature_set=[3.0.2] 
>    volnames=[dmfhome,dmfjrnls,dmfspool,dmftmp,diskmsp,data] 
>    CRM_meta_timeout=[20000]  to the operation list. 
> Nov 17 17:47:07 gto2 corosync[13452]:  [TOTEM ] mcasted message added to  
> pending queue 
> Nov 17 17:47:07 gto2 crmd: [13478]: info: te_rsc_command: Initiating action  
> 12: monitor  
> CXFS_monitor_0 on gto3 
> Nov 17 17:47:07 gto2 lrmd: [13475]: info: rsc:CXFS:2: probe 
> Note that the timeout for this operation is 20s (20000ms). Note also that it  
> is the monitor  
> operation for the resource that is actually called. The monitor operation  
> timeout for this resource  
> is set to 60s. Even manually defining a "probe" operation for the resource  
> with a longer timeout is  
> not effective. The timeout that is being used for this operation is the  
> cluster default operation  
> timeout. 

A probe is a special case of the monitor op, with an interval of 0.
Try configuring it like this:

  primitive CXFS ocf:sgi:cxfs \
    op monitor interval="60s" timeout="60s" \
    op start timeout="600s" \
    op stop timeout="600s" \
    op monitor interval="0" timeout="600s"

The timeout of 600s on the monitor op with the interval of zero should
thus be used when doing the probe.  The timeout of 60s should be used
on the recurring monitor op with the 60s interval.

> [...]
> I have two questions: 
>    1. Is this problem a known problem in the community and has it 
>       already been fixed? If so, by what mod?

If it doesn't work as I've described above, then it will very shortly
be a known problem :)

>    2. Is there somewhere I can go to keyword search a database of 
>       known problems/fixes so I need not bother the community 
>       answering these sorts of questions? 

There's the Linux Foundation bugzilla:


There's also a few mercurial repos.  Commit messages tend to be fairly




Tim Serong <tserong at novell.com>
Senior Clustering Engineer, OPS Engineering, Novell Inc.

More information about the Pacemaker mailing list