The FreeBSD 7 Agent was inadvertently a Linux binary.

shell> file mysqlmonitoragent-2.0.5.7153-freebsd7-x86-32bit-installer.bin
mysqlmonitoragent-2.0.5.7153-freebsd7-x86-32bit-installer.bin: ELF 32-bit LSB executable,
Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs),
stripped

(Bug#44263)

Calling the Agent with the option --agent-run-os-tests resulted in a crash. This happened on Linux x86-64 systems. The resultant stack trace was:

(qa-merlin)
2009-03-04 16:39:42: (critical) chassis.c:1097: could not raise RLIMIT_NOFILE to 8192,
Invalid argument (22). Current limit still 1024.
sigar-test-all.c.124 (test_sigar_pid_get):
  pid = 5188
sigar-test-all.c.106 (test_sigar_mem_get):
...cut...
sigar-test-all.c.427 (test_sigar_file_system_list_get): (items = 13)
[0]
  fs.dirname = /
  fs.devname = /dev/mapper/vg00-root
  fs.typename = local
  fs.sys-type-name = ext3
  fs.type = 2
  fsusage.total = 15481840
  fsusage.free = 14116140
  fsusage.used = 1365700
  fsusage.avail = 13329708
  fsusage.files = 1966080
  fsusage.use_percent = 0.100000
[0]
  diskusage.reads = 315302
  diskusage.writes = 6318240
  diskusage.write_bytes = 25879511040
  diskusage.read_bytes = 6561092608
  diskusage.queue = 47457530080206
Segmentation fault

On some systems no output was shown, other than the message “Segmentation fault”. (Bug#43381)

Following a change in the replication configuration, MySQL Enterprise Monitor did not display the new topology correctly. (Bug#43240)

When a data collection became invalid, the agent sent NULLs for those collection values. However, the timestamps that it sent with the values were the timestamps from the last valid value that was collected.

Due to key constraints on the Service Manager side, MySQL Enterprise Monitor disregarded anything sent with duplicate timestamps, thus the NULLs received from the agent were never processed. Some mechanisms, such as replication discovery, depend on the NULLs to identify a situation where data has become invalid. (Bug#43239)

MySQL Enterprise Monitor did not add a log entry each time data was purged. The log entry should have noted how many rows of each type of data were purged (historical data, logs, quan data). (Bug#43159)

MySQL Enterprise Monitor generated a stack overflow. This was as a result of a bug in Hibernate, which caused Hibernate to enter infinite recursion while trying to load a relationship. (Bug#43107)

The “Table Cache Set Too Low For Startup” and “Table Cache Not Optimal” rules were not supported on MySQL 5.1 because the table_cache system variable was deprecated and replaced with table_open_cache. (Bug#42663)

Migrated server was not completely deleted.

In a Monitor that had been updated from 1.3.2 to 2.0.4, with 2 database servers queued for migration, if a server being migrated was deleted, or a migrated server was deleted, this would not be reflected in the user interface or in the license count, until Tomcat was restarted. (Bug#42604)

The installer used to upgrade from version 1.3 corrupted passwords containing the “?” character. (Bug#42452)

The replication status of a server was displayed as “unknown”. However, the agent logged no errors and the server showed no other event problems. The server status was displayed as “up” and the database connection was also displayed as “up”. (Bug#42407)

Sun multi-core processors caused all cores to be reported on the meta information page.

The larger T-series SPARC processors have 32+ cores. This caused the meta information page in the Dashboard to scroll as it reported each one. (Bug#42355)

If an attempt was made to disable a rule using the link next to the rule, the following error message was generated:

U0002 You must log in to access the requested resource. Go to login page.

However, clicking on the link did not prompt the user to login again. (Bug#42313)

Changing ssh-agent from OpenSSH or specifying a malevolent value of agent-host-id, could inject data into the monitored MySQL Server.

For example, setting agent-host-id to the value “I'm a test” would result in the following message in the error log:

2009-01-23 15:45:11: ((error)) agent_mysqld.c:281: mysql_real_query('INSERT INTO
mysql.inventory  (name, value) VALUES ( 'hostid', 'I'm a test' )') on 'mysql' failed: You
have an error in your SQL syntax; check the manual that corresponds to your MySQL server
version for the right syntax to use near 'm a test' )' at line 1 (mysql-errno = 1064)

(Bug#42306)

When SHOW GLOBAL STATUS returned a value greater than 214748364, it was sent to the Service Manager as 214748364. (Bug#42245)

The Agent failed to identify local sockets as local on Mac OS X 10.4.

If the Agent was configured to use a Unix domain socket on Mac OS X 10.4, it did not treat the connection as local and failed to provide CPU and memory information to MySQL Enterprise Monitor. This is shown in the log file:

2009-01-20 18:15:02: (message) network-socket.c:752: is-local family 0 != 1
2009-01-20 18:15:02: (message) agent_mysqld.c:322: [mysql] mysqld is not local or not
directly connected

However, this problem did not happen on Mac OS X 10.5. (Bug#42220)

Some graphs on the Graph tab were not updated after the page was refreshed, or Update was clicked.

The only way to get an updated graph was to change the graph size (in pixels) and then click Update. (Bug#42162)

The my.cnf file for the Enterprise Monitor internal database had the following configuration item:

innodb_autoextend_increment = 50M

This generated the error:

16:36:23 [Warning] option 'innodb_autoextend_increment': unsigned value 52428800
adjusted to 1000

This variable is interpreted as being specified in MB, so 50M would be 50 TB. Such a high value results in the variable being adjusted to 1000 MB.

The value in the configuration file should be:

innodb_autoextend_increment = 50

(Bug#42096)

A number of Advisor rules had advice text that had not been translated into Japanese. The Advisors that contained untranslated rules included Performance, Schema and Security. (Bug#42067)

The Service Manager did not handle the case where the agent failed to supply a valid master_ip. The Service Manager would then not restart. The logs contained the following:

2009-01-09 14:39:50,472 ERROR [main:org.springframework.web.context.ContextLoader] Context
initialization failed
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with
name 'serverConnectionMonitor' defined in ServletContext resource
[/WEB-INF/applicationContext.xml]: Unsatisfied dependency expressed through constructor
argument with index 2 of type [com.mysql.etools.monitor.bo.Manager]: Error creating bean
with name 'manager' defined in ServletContext resource [/WEB-INF/applicationContext.xml]:
Invocation of init method failed; nested exception is
com.mysql.etools.monitor.pom.UnsupportedAttributeException:
101c6b5b-15eb-49aa-916c-843c51b28d38: mysql.slavestatus.Master_ip

(Bug#42005)

Having too many users with strong privileges generated Service Manager errors and events failed to be triggered.

If there were approximately 1000 users with full privileges and the value of group_concat_max_len was set to 100001, the size of the data that the agent sent to the Service Manager was too large and caused Service Manager errors. Also, the Security event “Account has Strong MySQL privileges” did not trigger. (Bug#41987)

Query Analyzer's Query Type filter for SELECT ignored statements starting with parenthesis.

If you sent a statement through Query Analyzer starting with parenthesis, such as:

(SELECT 1 FROM dual);

and then attempted to filter for SELECT queries only, queries starting with parenthesis were not displayed. (Bug#41968)

The agent angel process was spawning too soon, which caused a duplicate UUID error.

g_error() logged a fatal error, and called abort(). This terminated the program. Then the angel respawned with the same UUID, but with a -1 session resync request, which the MEM server denied because the old session was still active. This resulted in a permissions denied error (1142) on the mysql.inventory table.

2008-12-17 18:58:58: (message) agent_mysqld.c:313: [mysql] mysqld is local and directly connected
2008-12-17 18:58:58: ((error)) agent_mysqld.c:444: [mysql] mysql_real_query("SELECT value
FROM mysql.inventory WHERE name = 'uuid'") failed: SELECT command denied to user
'ent_agent'@'127.0.0.1' for table 'inventory' (errno=1142)
2008-12-17 18:58:58: (debug) chassis.c:282: 15134 returned: 15134
2008-12-17 18:58:58: (message) chassis.c:304: [angel] PID=15134 died on signal=6 (it used
0 kBytes max) ... waiting 3min before restart
2008-12-17 18:59:00: (debug) chassis.c:244: we are the child: 15149
2008-12-17 18:59:00: (message) chassis.c:259: [angel] we try to keep PID=15149 alive
2008-12-17 18:59:00: (debug) chassis.c:277: waiting for 15149
2008-12-17 18:59:00: (message) mysql-proxy 0.7.0 started
2008-12-17 18:59:00: (message) MySQL Monitor Agent 2.0.0.7111 started.

(Bug#41600)

master_uuid discovery did not work with MySQL Server versions prior to 5.1. master_uuid did not show in any Agent to Monitor communications, and no log or error messages were generated.

However, now the bug has been fixed, an Agent monitoring a 5.0 MySQL Server would register the following in its logs:

...
 <classname>slavestatus</classname>
 <instance>12515cdc-8c00-4223-9d2a-2666a403512c</instance>
 <attribute>Master_uuid</attribute>
</target>
<utc>2009-03-03T19:58:05.700Z</utc>
<value>b2fd9f86-6e42-49f2-b930-e8fb3e728179</value>

Note the presence of master_uuid. (Bug#41525)

The master_uuid was not used for replication topology discovery.

The agent collected master_uuid by reading the master.info file, and then running a SELECT directly against its master. This was to try and read the mysql.inventory table on the master to obtain the instance master_uuid.

However, this was not being used correctly by the replication topology discovery within the server. (Bug#41519)

Queries such as SELECT against the master mysql.inventory was not logged on slave-based agents. This made diagnosing topology discovery issues difficult. (Bug#41518)

After an error was generated due to an incorrect password while trying to create a new user, the following error was obtained when subsequently attempting to create a valid new user:

U0002 You must log in to access the requested resource

(Bug#41384)

Agent startup failed on Solaris 10. The error generated was:

# ./mysql-monitor-agent start
Bad string
ERROR! /opt/mysql/enterprise/agent/etc/mysql-monitor-agent.ini has to have a
[mysql-proxy].pid-file setting

This was caused by unexpected behavior of the tr command. (Bug#41260)

On the Query Analysis page, if a query was clicked the minimum displayed was greater than the average. (Bug#41259)

In some circumstances the agent/proxy ran out of file descriptors, causing secondary failures. It could not recover from that state. The relevant part of the log file is shown here:

2008-11-27 11:11:00: (critical) last message repeated 2 times
2008-11-27 11:11:00: (critical) job_collect_os.c:411: sigar_cpu_info_list_get() failed
2008-11-27 11:11:00: (critical) job_collect_os.c:445: sigar_cpu_list_get() failed
2008-11-27 11:11:00: (critical) job_collect_os.c:411: sigar_cpu_info_list_get() failed
2008-11-27 11:11:00: (critical) job_collect_os.c:445: sigar_cpu_list_get() failed
2008-11-27 11:11:00: (critical) job_collect_os.c:411: sigar_cpu_info_list_get() failed
2008-11-27 11:11:00: (critical) job_collect_os.c:445: sigar_cpu_list_get() failed
2008-11-27 11:11:00: (critical) job_collect_os.c:411: sigar_cpu_info_list_get() failed
2008-11-27 11:11:00: (critical) job_collect_os.c:445: sigar_cpu_list_get() failed
2008-11-27 11:11:30: (critical) network-socket.c.292: socket(127.0.0.1:3306) failed: Too many open files (24)
2008-11-27 11:11:30: (critical) proxy-plugin.c.1532: Cannot connect, all backends are down.
2008-11-27 11:20:22: (critical) last message repeated 4 times
2008-11-27 11:20:22: (critical) network-io.c:215:
curl_easy_perform('https://user:password@merlin-dashboard:443/heartbeat') failed:
SSL connection timeout (curl-error = 'Timeout was reached' (28), os-error = 'Connection refused' (111))

(Bug#41068)

If an installation of Service Manager 2.0.0.7102 included a backup directory, due to a previous upgrade, and was upgraded using at least Service Manager 2.0.0.7103, then the installer displayed an error message and exited.

The error message displayed was:

There has been an error.
Error renaming /Applications/mysql/enterprise/monitor/apache-tomcat to
/Applications/mysql/enterprise/monitor/backup/apache-tomcat
The application will exit now

(Bug#40996)

The Agent started without problems and connected to the master. But it was unable to perform a SELECT from the table mysql.inventory in order to obtain server information. (Bug#40933)

Canonical Query Text for Select -1 was displayed as SELECT -? instead of SELECT ? on the Query Analyzer tab. (Bug#40435)

The agent installer for Solaris 8 x86 32-bit was missing. (Bug#40248)

The MySQL Enterprise Monitor Dashboard did not display the subscribed notification group(s) on the Advisor Current Scheduled and Add to Schedule pages. (Bug#36007)

The startup scripts supplied with MySQL Network Monitoring and Advisory tool did not supply all of the LSB init.d script options required. A list of the required options can be found at the following website http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

The required options missing include status and force-reload. The option status is used by monitoring tools and cluster software such as Red Hat Cluster, to ensure that the service is still running. The force-reload option is an alias for restart. (Bug#29848)

Multiple errors showed in the agent log after issuing a SHOW INNODB STATUS statement. The InnoDB Buffer Poolgraph also went blank. (Bug#27372)