[ClusterLabs] [Problem] The SNMP trap which has been already started is transmitted.
renayama19661014 at ybb.ne.jp
renayama19661014 at ybb.ne.jp
Sun Aug 16 21:05:15 EDT 2015
Hi Andrew,
Thank you for comments.
I will confirm it tomorrow.
I am a vacation today.
Best Regards,
Hideo Yamauchi.
----- Original Message -----
> From: Andrew Beekhof <andrew at beekhof.net>
> To: renayama19661014 at ybb.ne.jp; Cluster Labs - All topics related to open-source clustering welcomed <users at clusterlabs.org>
> Cc:
> Date: 2015/8/17, Mon 09:30
> Subject: Re: [ClusterLabs] [Problem] The SNMP trap which has been already started is transmitted.
>
>
>> On 4 Aug 2015, at 7:36 pm, renayama19661014 at ybb.ne.jp wrote:
>>
>> Hi Andrew,
>>
>> Thank you for comments.
>>
>>>> However, a trap of crm_mon is sent to an SNMP manager.
>>>
>>> Are you using the built-in SNMP logic or using -E to give crm_mon a
> script which
>>> is then producing the trap?
>>> (I’m trying to figure out who could be turning the monitor action into
> a start)
>>
>>
>> I used the built-in SNMP.
>> I started as a daemon with -d option.
>
> Is it running on both nodes or just snmp1?
> Because there is no logic in crm_mon that would have remapped the monitor to
> start, so my working theory is that its a duplicate of an old event.
> Can you tell which node the trap is being sent from?
>
>>
>>
>> Best Regards,
>> Hideo Yamauchi.
>>
>>
>> ----- Original Message -----
>>> From: Andrew Beekhof <andrew at beekhof.net>
>>> To: renayama19661014 at ybb.ne.jp; Cluster Labs - All topics related to
> open-source clustering welcomed <users at clusterlabs.org>
>>> Cc:
>>> Date: 2015/8/4, Tue 14:15
>>> Subject: Re: [ClusterLabs] [Problem] The SNMP trap which has been
> already started is transmitted.
>>>
>>>
>>>> On 27 Jul 2015, at 4:18 pm, renayama19661014 at ybb.ne.jp wrote:
>>>>
>>>> Hi All,
>>>>
>>>> The transmission of the SNMP trap of crm_mon seems to have a
> problem.
>>>> I identified a problem on latest Pacemaker and Pacemaker1.1.13.
>>>>
>>>>
>>>> Step 1) I constitute a cluster and send simple CLI file.
>>>>
>>>> [root at snmp1 ~]# crm_mon -1
>>>> Last updated: Mon Jul 27 14:40:37 2015 Last change: Mon
> Jul 27
>>> 14:40:29 2015 by root via cibadmin on snmp1
>>>> Stack: corosync
>>>> Current DC: snmp1 (version 1.1.13-3d781d3) - partition with quorum
>>>> 2 nodes and 1 resource configured
>>>>
>>>> Online: [ snmp1 snmp2 ]
>>>>
>>>> prmDummy (ocf::heartbeat:Dummy): Started snmp1
>>>>
>>>> Step 2) I stop a node of the standby once.
>>>>
>>>> [root at snmp2 ~]# stop pacemaker
>>>> pacemaker stop/waiting
>>>>
>>>>
>>>> Step 3) I start a node of the standby again.
>>>> [root at snmp2 ~]# start pacemaker
>>>> pacemaker start/running, process 2284
>>>>
>>>> Step 4) The indication of crm_mon does not change in particular.
>>>> [root at snmp1 ~]# crm_mon -1
>>>> Last updated: Mon Jul 27 14:45:12 2015 Last change: Mon
> Jul 27
>>> 14:40:29 2015 by root via cibadmin on snmp1
>>>> Stack: corosync
>>>> Current DC: snmp1 (version 1.1.13-3d781d3) - partition with quorum
>>>> 2 nodes and 1 resource configured
>>>>
>>>> Online: [ snmp1 snmp2 ]
>>>>
>>>> prmDummy (ocf::heartbeat:Dummy): Started snmp1
>>>>
>>>>
>>>> In addition, as for the resource that started in snmp1 node,
> nothing
>>> changes.
>>>>
>>>> -------
>>>> Jul 27 14:41:39 snmp1 crmd[29116]: notice: State transition
> S_IDLE ->
>>> S_POLICY_ENGINE [ input=I_PE_CALC cause=C_FSA_INTERNAL
>>> origin=abort_transition_graph ]
>>>> Jul 27 14:41:39 snmp1 cib[29111]: info: Completed cib_modify
> operation
>>> for section status: OK (rc=0, origin=snmp1/attrd/11, version=0.4.20)
>>>> Jul 27 14:41:39 snmp1 attrd[29114]: info: Update 11 for
> probe_complete:
>>> OK (0)
>>>> Jul 27 14:41:39 snmp1 attrd[29114]: info: Update 11 for
>>> probe_complete[snmp1]=true: OK (0)
>>>> Jul 27 14:41:39 snmp1 attrd[29114]: info: Update 11 for
>>> probe_complete[snmp2]=true: OK (0)
>>>> Jul 27 14:41:39 snmp1 cib[29202]: info: Wrote version 0.4.0 of
> the CIB
>>> to disk (digest: a1f1920279fe0b1466a79cab09fa77d6)
>>>> Jul 27 14:41:39 snmp1 pengine[29115]: notice: On loss of CCM
> Quorum:
>>> Ignore
>>>> Jul 27 14:41:39 snmp1 pengine[29115]: info: Node snmp2 is
> online
>>>> Jul 27 14:41:39 snmp1 pengine[29115]: info: Node snmp1 is
> online
>>>> Jul 27 14:41:39 snmp1 pengine[29115]: info:
>>> prmDummy#011(ocf::heartbeat:Dummy):#011Started snmp1
>>>> Jul 27 14:41:39 snmp1 pengine[29115]: info: Leave
>>> prmDummy#011(Started snmp1)
>>>> -------
>>>>
>>>> However, a trap of crm_mon is sent to an SNMP manager.
>>>
>>> Are you using the built-in SNMP logic or using -E to give crm_mon a
> script which
>>> is then producing the trap?
>>> (I’m trying to figure out who could be turning the monitor action into
> a start)
>>>
>>>> The resource does not reboot, but the SNMP trap which a resource
> started is
>>> sent.
>>>>
>>>> -------
>>>> Jul 27 14:41:39 SNMP-MANAGER snmptrapd[4521]: 2015-07-27 14:41:39
> snmp1
>>> [UDP:
>>>
> [192.168.40.100]:35265->[192.168.40.2]]:#012DISMAN-EVENT-MIB::sysUpTimeInstance
>
>>> = Timeticks: (1437975699) 166 days,
> 10:22:36.99#011SNMPv2-MIB::snmpTrapOID.0 =
>>> OID:
>>>
> PACEMAKER-MIB::pacemakerNotification#011PACEMAKER-MIB::pacemakerNotificationResource
>
>>> = STRING:
> "prmDummy"#011PACEMAKER-MIB::pacemakerNotificationNode =
>>> STRING:
> "snmp1"#011PACEMAKER-MIB::pacemakerNotificationOperation =
>>> STRING:
> "start"#011PACEMAKER-MIB::pacemakerNotificationDescription =
>>> STRING:
> "OK"#011PACEMAKER-MIB::pacemakerNotificationReturnCode =
>>> INTEGER: 0#011PACEMAKER-MIB::pacemakerNotificationTargetReturnCode =
> INTEGER:
>>> 0#011PACEMAKER-MIB::pacemakerNotificationStatus = INTEGER: 0
>>>> Jul 27 14:41:39 SNMP-MANAGER snmptrapd[4521]: 2015-07-27 14:41:39
> snmp1
>>> [UDP:
>>>
> [192.168.40.100]:35265->[192.168.40.2]]:#012DISMAN-EVENT-MIB::sysUpTimeInstance
>
>>> = Timeticks: (1437975699) 166 days,
> 10:22:36.99#011SNMPv2-MIB::snmpTrapOID.0 =
>>> OID:
>>>
> PACEMAKER-MIB::pacemakerNotification#011PACEMAKER-MIB::pacemakerNotificationResource
>
>>> = STRING:
> "prmDummy"#011PACEMAKER-MIB::pacemakerNotificationNode =
>>> STRING:
> "snmp1"#011PACEMAKER-MIB::pacemakerNotificationOperation =
>>> STRING:
> "monitor"#011PACEMAKER-MIB::pacemakerNotificationDescription =
>>> STRING:
> "OK"#011PACEMAKER-MIB::pacemakerNotificationReturnCode =
>>> INTEGER: 0#011PACEMAKER-MIB::pacemakerNotificationTargetReturnCode =
> INTEGER:
>>> 0#011PACEMAKER-MIB::pacemakerNotificationStatus = INTEGER: 0
>>>> -------
>>>>
>>>> A difference of CIB occurring by the start stop of the node seems
> to have a
>>> problem.
>>>> By this difference, crm_mon transmits an unnecessary SNMP trap.
>>>> -------
>>>> Jul 27 14:41:39 snmp1 cib[29111]: info: + /cib:
> @num_updates=19
>>>> Jul 27 14:41:39 snmp1 cib[29111]: info: +
>>> /cib/status/node_state[@id='3232238190']:
>>> @crm-debug-origin=do_update_resource
>>>> Jul 27 14:41:39 snmp1 cib[29111]: info: ++
>>>
> /cib/status/node_state[@id='3232238190']/lrm[@id='3232238190']/lrm_resources:
>
>>> <lrm_resource id="prmDummy" type="Dummy"
>>> class="ocf" provider="heartbeat"/>
>>>> Jul 27 14:41:39 snmp1 cib[29111]: info: ++
>
>>> <lrm_rsc_op
>>> id="prmDummy_last_0"
> operation_key="prmDummy_monitor_0"
>>> operation="monitor"
> crm-debug-origin="do_update_resource"
>>> crm_feature_set="3.0.10"
>>> transition-key="6:6:7:34187f48-1f81-49c8-846e-ff3ed4c8f787"
>>>
> transition-magic="0:7;6:6:7:34187f48-1f81-49c8-846e-ff3ed4c8f787"
>>> on_node="snmp2" call-id="5" rc-code="7"
>>> op-status="0" interval="0"
> last-run="1437975699"
>>> last-rc-change="1437975699" exec-time="18" queue-ti
>>>> Jul 27 14:41:39 snmp1 cib[29111]: info: ++
>
>>> </lrm_resource>
>>>> -------
>>>>
>>>> I registered this problem with Bugzilla.
>>>> * http://bugs.clusterlabs.org/show_bug.cgi?id=5245
>>>> * The log attached it to Bugzilla.
>>>>
>>>> Best Regards,
>>>> Hideo Yamauchi.
>>>>
>>>> _______________________________________________
>>>> Users mailing list: Users at clusterlabs.org
>>>> http://clusterlabs.org/mailman/listinfo/users
>>>>
>>>> Project Home: http://www.clusterlabs.org
>>>> Getting started:
> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>>> Bugs: http://bugs.clusterlabs.org
>>>
>>
>> _______________________________________________
>> Users mailing list: Users at clusterlabs.org
>> http://clusterlabs.org/mailman/listinfo/users
>>
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://bugs.clusterlabs.org
>
More information about the Users
mailing list