Bug #50449 Agent reports old timestamps for mysqld info under corner case

Submitted: 19 Jan 2010 16:11 Modified: 14 Jun 2010 9:36
Reporter: Diego Medina Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Enterprise Monitor: Agent Severity:S3 (Non-critical)
Version:2.1.0.1096 OS:Any
Assigned to: Kay Roepke CPU Architecture:Any
Tags: windmill

[19 Jan 2010 16:11] Diego Medina
Description:
It is possible to get the agent in a state where it will report mysqld data with an old timestamp.

How to repeat:
With the agent log in debug mode do:

1- start an agent against a running instance properly
2- change the agent password (the one that the agent uses to connect to 
mysqld
2.5- flush privileges ;
3- stop the mysqld instance
4- start the mysqld instance
5- check what times are being reported for dc in the debug logs
6- the agent should *not* be able to reconnect to the db..

To verify 6 you can do: 

$ tail -f agent.log | grep critical

To verify 5 do: 

$ tail -f agent.log | grep utc

and you would see something like 

============
<utc>2010-01-19T16:00:07.312Z</utc>
     <utc>2010-01-19T15:52:01.296Z</utc>
   <utc>2010-01-19T16:00:07.312Z</utc>
     <utc>2010-01-19T16:00:01.331Z</utc>
   <utc>2010-01-19T16:00:07.312Z</utc>
     <utc>2010-01-19T15:52:01.296Z</utc>
   <utc>2010-01-19T16:00:07.313Z</utc>
     <utc>2010-01-19T16:00:01.331Z</utc>
===========
Note the entries with 15:52:01, those are the wrong value, they should all be 16:00 (or close to that)
[19 Jan 2010 16:12] Diego Medina
data showing the old timestamp 

<task>
   <taskId>33417</taskId>
   <command>collect_data</command>
   <utc>2010-01-19T16:01:07.321Z</utc>
   <data>
    <datum>
     <target>
      <namespace>mysql</namespace>
      <classname>variables</classname>
      <instance>c02e030a-c5be-4b39-b34e-8fad04b72985</instance>
      <attribute>query_cache_size</attribute>
     </target>
     <utc>2010-01-19T15:52:01.303Z</utc>
     <value>0</value>
    </datum>
   </data>
  </task>
  <task>

--------------
  <task>
   <taskId>33371</taskId>
   <command>collect_data</command>
   <utc>2010-01-19T16:01:07.321Z</utc>
   <data>
    <datum>
     <target>
      <namespace>mysql</namespace>
      <classname>variables</classname>
      <instance>c02e030a-c5be-4b39-b34e-8fad04b72985</instance>
      <attribute>max_connections</attribute>
     </target>
     <utc>2010-01-19T15:52:01.303Z</utc>
     <value>151</value>
    </datum>
   </data>
  </task>
  <task>

----------------------
  <task>
   <taskId>33342</taskId>
   <command>collect_data</command>
   <utc>2010-01-19T16:01:07.321Z</utc>
   <data>
    <datum>
     <target>
      <namespace>mysql</namespace>
      <classname>variables</classname>
      <instance>c02e030a-c5be-4b39-b34e-8fad04b72985</instance>
      <attribute>key_cache_block_size</attribute>
     </target>
     <utc>2010-01-19T15:52:01.303Z</utc>
     <value>1024</value>
    </datum>
   </data>
  </task>
  <task>
[19 Jan 2010 16:23] Enterprise Tools JIRA Robot
Diego Medina writes: 
Agent log in debug mode
[3 Feb 2010 17:41] Enterprise Tools JIRA Robot
Keith Russell writes: 
Patch installed in versions => 2.1.1.1145.
[3 Jun 2010 18:22] Enterprise Tools JIRA Robot
Diego Medina writes: 
Never mind my last comment, it was fixed.
[14 Jun 2010 9:36] MC Brown
A note has been added to the 2.1.1 changelog: 

        The &merlin_agent; could report data using an old timestamp,                                                                     
        or report information for a server that the &merlin_agent; can                                                                   
        no longer connect to due to a permissions change.

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.065 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.