[ClusterLabs] Cannot clean history

Alexandre alxgomz at gmail.com
Tue May 26 08:58:15 UTC 2015


Hi Andrew,

Here is the output of the verbose crm_failcount.

   trace: set_crm_log_level:     New log level: 8
   trace: cib_native_signon_raw:     Connecting cib_rw channel
   trace: pick_ipc_buffer:     Using max message size of 524288
   debug: qb_rb_open_2:     shm size:524301; real_size:528384;
rb->word_size:132096
   debug: qb_rb_open_2:     shm size:524301; real_size:528384;
rb->word_size:132096
   debug: qb_rb_open_2:     shm size:524301; real_size:528384;
rb->word_size:132096
   trace: mainloop_add_fd:     Added connection 1 for cib_rw[0x1fd79c0].4
   trace: pick_ipc_buffer:     Using max message size of 51200
   trace: crm_ipc_send:     Sending from client: cib_rw request id: 1
bytes: 131 timeout:-1 msg...
   trace: crm_ipc_send:     Recieved response 1, size=140, rc=140, text:
<cib_common_callback_worker cib_op="register"
cib_clientid="f8cfae2d-51e6-4cd7-97f8-2d6f49bf1f17"/>
   trace: cib_native_signon_raw:     reg-reply
<cib_common_callback_worker cib_op="register"
cib_clientid="f8cfae2d-51e6-4cd7-97f8-2d6f49bf1f17"/>
   debug: cib_native_signon_raw:     Connection to CIB successful
   trace: cib_create_op:     Sending call options: 00001100, 4352
   trace: cib_native_perform_op_delegate:     Sending cib_query message to
CIB service (timeout=120s)
   trace: crm_ipc_send:     Sending from client: cib_rw request id: 2
bytes: 211 timeout:120000 msg...
   trace: internal_ipc_get_reply:     client cib_rw waiting on reply to msg
id 2
   trace: crm_ipc_send:     Recieved response 2, size=944, rc=944, text:
<cib-reply t="cib" cib_op="cib_query" cib_callid="2"
cib_clientid="f8cfae2d-51e6-4cd7-97f8-2d6f49bf1f17" cib_callopt="4352"
cib_rc="0"><cib_calldata><nodes><node uname="node2.domain.com" id="o
   trace: cib_native_perform_op_delegate:     Reply   <cib-reply t="cib"
cib_op="cib_query" cib_callid="2"
cib_clientid="f8cfae2d-51e6-4cd7-97f8-2d6f49bf1f17" cib_callopt="4352"
cib_rc="0">
   trace: cib_native_perform_op_delegate:     Reply     <cib_calldata>
   trace: cib_native_perform_op_delegate:     Reply       <nodes>
   trace: cib_native_perform_op_delegate:     Reply         <node uname="
node2.domain.com" id="node2.domain.com">
   trace: cib_native_perform_op_delegate:     Reply
<instance_attributes id="nodes-node2.domain.com">
   trace: cib_native_perform_op_delegate:     Reply             <nvpair
id="nodes-node2.domain.com-postgres_msg-data-status"
name="postgres_msg-data-status" value="STREAMING|SYNC"/>
   trace: cib_native_perform_op_delegate:     Reply             <nvpair
id="nodes-node2.domain.com-standby" name="standby" value="off"/>
   trace: cib_native_perform_op_delegate:     Reply
</instance_attributes>
   trace: cib_native_perform_op_delegate:     Reply         </node>
   trace: cib_native_perform_op_delegate:     Reply         <node uname="
node1.domain.com" id="node1.domain.com">
   trace: cib_native_perform_op_delegate:     Reply
<instance_attributes id="nodes-node1.domain.com">
   trace: cib_native_perform_op_delegate:     Reply             <nvpair
id="nodes-node1.domain.com-postgres_msg-data-status"
name="postgres_msg-data-status" value="LATEST"/>
   trace: cib_native_perform_op_delegate:     Reply             <nvpair
id="nodes-node1.domain.com-standby" name="standby" value="off"/>
   trace: cib_native_perform_op_delegate:     Reply
</instance_attributes>
   trace: cib_native_perform_op_delegate:     Reply         </node>
   trace: cib_native_perform_op_delegate:     Reply       </nodes>
   trace: cib_native_perform_op_delegate:     Reply     </cib_calldata>
   trace: cib_native_perform_op_delegate:     Reply   </cib-reply>
   trace: cib_native_perform_op_delegate:     Syncronous reply 2 received
   debug: get_cluster_node_uuid:     Result section   <nodes>
   debug: get_cluster_node_uuid:     Result section     <node uname="
node2.domain.com" id="node2.domain.com">
   debug: get_cluster_node_uuid:     Result section
<instance_attributes id="nodes-node2.domain.com">
   debug: get_cluster_node_uuid:     Result section         <nvpair
id="nodes-node2.domain.com-postgres_msg-data-status"
name="postgres_msg-data-status" value="STREAMING|SYNC"/>
   debug: get_cluster_node_uuid:     Result section         <nvpair
id="nodes-node2.domain.com-standby" name="standby" value="off"/>
   debug: get_cluster_node_uuid:     Result section
</instance_attributes>
   debug: get_cluster_node_uuid:     Result section     </node>
   debug: get_cluster_node_uuid:     Result section     <node uname="
node1.domain.com" id="node1.domain.com">
   debug: get_cluster_node_uuid:     Result section
<instance_attributes id="nodes-node1.domain.com">
   debug: get_cluster_node_uuid:     Result section         <nvpair
id="nodes-node1.domain.com-postgres_msg-data-status"
name="postgres_msg-data-status" value="LATEST"/>
   debug: get_cluster_node_uuid:     Result section         <nvpair
id="nodes-node1.domain.com-standby" name="standby" value="off"/>
   debug: get_cluster_node_uuid:     Result section
</instance_attributes>
   debug: get_cluster_node_uuid:     Result section     </node>
   debug: get_cluster_node_uuid:     Result section   </nodes>
    info: query_node_uuid:     Mapped node1.domain.com to node1.domain.com
   trace: pick_ipc_buffer:     Using max message size of 51200
    info: attrd_update_delegate:     Connecting to cluster... 5 retries
remaining
   debug: qb_rb_open_2:     shm size:51213; real_size:53248;
rb->word_size:13312
   debug: qb_rb_open_2:     shm size:51213; real_size:53248;
rb->word_size:13312
   debug: qb_rb_open_2:     shm size:51213; real_size:53248;
rb->word_size:13312
   trace: crm_ipc_send:     Sending from client: attrd request id: 3 bytes:
168 timeout:5000 msg...
   trace: internal_ipc_get_reply:     client attrd waiting on reply to msg
id 3
   trace: crm_ipc_send:     Recieved response 3, size=88, rc=88, text: <ack
function="attrd_ipc_dispatch" line="129"/>
   debug: attrd_update_delegate:     Sent update: (null)=(null) for
node1.domain.com
    info: main:     Update (null)=<none> sent via attrd
   debug: cib_native_signoff:     Signing out of the CIB Service
   trace: mainloop_del_fd:     Removing client cib_rw[0x1fd79c0]
   trace: mainloop_gio_destroy:     Destroying client cib_rw[0x1fd79c0]
   trace: crm_ipc_close:     Disconnecting cib_rw IPC connection 0x1fdb020
(0x1fdb1a0.(nil))
   debug: qb_ipcc_disconnect:     qb_ipcc_disconnect()
   trace: qb_rb_close:     ENTERING qb_rb_close()
   debug: qb_rb_close:     Closing ringbuffer:
/dev/shm/qb-cib_rw-request-8347-9344-14-header
   trace: qb_rb_close:     ENTERING qb_rb_close()
   debug: qb_rb_close:     Closing ringbuffer:
/dev/shm/qb-cib_rw-response-8347-9344-14-header
   trace: qb_rb_close:     ENTERING qb_rb_close()
   debug: qb_rb_close:     Closing ringbuffer:
/dev/shm/qb-cib_rw-event-8347-9344-14-header
   trace: cib_native_destroy:     destroying 0x1fd7910
   trace: crm_ipc_destroy:     Destroying IPC connection to cib_rw:
0x1fdb020
   trace: mainloop_gio_destroy:     Destroyed client cib_rw[0x1fd79c0]
   trace: crm_exit:     cleaning up libxml
    info: crm_xml_cleanup:     Cleaning up memory from libxml2
   trace: crm_exit:     exit 0

I hope it helps.

2015-05-20 6:34 GMT+02:00 Andrew Beekhof <andrew at beekhof.net>:

>
> > On 4 May 2015, at 6:43 pm, Alexandre <alxgomz at gmail.com> wrote:
> >
> > Hi,
> >
> > I have a pacemaker / corosync / cman cluster running on redhat 6.6.
> > Although cluster is working as expected, I have some trace of old
> failures (several monthes ago) I can't gert rid of.
> > Basically I have set cluster-recheck-interval="300" and
> failure-timeout="600" (in rsc_defaults) as shown bellow:
> >
> > property $id="cib-bootstrap-options" \
> >     dc-version="1.1.10-14.el6-368c726" \
> >     cluster-infrastructure="cman" \
> >     expected-quorum-votes="2" \
> >     no-quorum-policy="ignore" \
> >     stonith-enabled="false" \
> >     last-lrm-refresh="1429702408" \
> >     maintenance-mode="false" \
> >     cluster-recheck-interval="300"
> > rsc_defaults $id="rsc-options" \
> >     failure-timeout="600"
> >
> > So I would expect old failure to be purged from the cib long ago, but
> actually I have the following when issuing crm_mon -frA1.
>
> I think automatic deletion didnt arrive until later.
>
> >
> > Migration summary:
> > * Node host1:
> >    etc_ml_drbd: migration-threshold=1000000 fail-count=244
> last-failure='Sat Feb 14 17:04:05 2015'
> >    spool_postfix_drbd_msg: migration-threshold=1000000 fail-count=244
> last-failure='Sat Feb 14 17:04:05 2015'
> >    lib_ml_drbd: migration-threshold=1000000 fail-count=244
> last-failure='Sat Feb 14 17:04:05 2015'
> >    lib_imap_drbd: migration-threshold=1000000 fail-count=244
> last-failure='Sat Feb 14 17:04:05 2015'
> >    spool_imap_drbd: migration-threshold=1000000 fail-count=11654
> last-failure='Sat Feb 14 17:04:05 2015'
> >    spool_ml_drbd: migration-threshold=1000000 fail-count=244
> last-failure='Sat Feb 14 17:04:05 2015'
> >    documents_drbd: migration-threshold=1000000 fail-count=248
> last-failure='Sat Feb 14 17:58:55 2015'
> > * Node host2
> >    documents_drbd: migration-threshold=1000000 fail-count=548
> last-failure='Sat Feb 14 16:26:33 2015'
> >
> > I have tried to crm_failcount -D the resources also tried cleanup... but
> it's still there!
>
> Oh?  Can you re-run with -VVVVVV and show us the result?
>
> > How can I get reid of those record (so my monitoring tools stop
> complaining) .
> >
> > Regards.
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20150526/791bf447/attachment.htm>


More information about the Users mailing list