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

Ron Kerry rkerry at sgi.com
Wed Nov 17 19:26:07 EST 2010

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]
   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 

<primitive class="ocf" id="CXFS" provider="sgi" type="cxfs">
  <operations id="CXFS-operations">
   <op id="CXFS-op-monitor-60s" interval="60s" name="monitor" on-fail="restart" timeout="60s"/>
   <op id="CXFS-op-start-0" interval="0" name="start" on-fail="restart" requires="fencing" 
   <op id="CXFS-op-stop-0" interval="0" name="stop" on-fail="fence" timeout="600s"/>
   <op id="CXFS-op-probe-0" interval="0" name="probe" timeout="600s"/>
  <instance_attributes id="CXFS-instance_attributes">
   <nvpair id="CXFS-instance_attributes-volnames" name="volnames" 
  <meta_attributes id="CXFS-meta_attributes">
   <nvpair id="CXFS-meta_attributes-resource-stickiness" name="resource-stickiness" value="1"/>
   <nvpair id="CXFS-meta_attributes-migration-threshold" name="migration-threshold" value="1"/>

It seems to me that this special "probe" operation should be using either the monitor operation 
timeout for each specific resource or a separately define probe operation timeout for each specific 
resource. Always using the cluster default operation timeout is just wrong.

These are the rpm levels in my test cluster where I can repeat this problem (SLE11-HAE-SP1).


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?
   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?


Ron Kerry         rkerry at sgi.com

More information about the Pacemaker mailing list