| Bug #74917 | Failed restarts contain no version details. | ||
|---|---|---|---|
| Submitted: | 18 Nov 2014 16:34 | Modified: | 11 Feb 2015 17:02 |
| Reporter: | Shawn Green | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Logging | Severity: | S3 (Non-critical) |
| Version: | OS: | Any | |
| Assigned to: | CPU Architecture: | Any | |
[11 Feb 2015 17:02]
Paul DuBois
Noted in 5.5.43, 5.6.24, 5.7.6 changelogs. The server now includes its version number when it writes the initial "starting" message to the error log, to make it easier to tell which server instance error log output applies to. This value is the same as that available from the version system variable.
[27 Apr 2015 14:12]
Laurynas Biveinis
commit ddd275bde7a8edb64449761989d4d472739b3d2a
Author: Praveenkumar.Hulakund <praveenkumar.hulakund@oracle.com>
Date: Fri Feb 6 11:09:08 2015 +0530
Bug#20052694 - FAILED RESTARTS CONTAIN NO VERSION DETAILS.
In versions 5.5 and 5.6 the MySQL version is not logged until
server is started and ready to accept connections. Exiting
server before this point will not have server version information
in the log. But in 5.7 code, we log a server version information
just after we prepare server_version string and logging is initialized.
For 5.5 and 5.6 code also adding this code to print server version
information.
Test results:
================
5.5
-----
Server version will be logged as below on server startup:
141218 8:45:48 [Note] /home/praveen/WorkDir/mysql_local/bug20052694/mysql/sql/mysqld (mysqld 5.5.42-debug-log) starting as process 19697 ...
5.6
----
Server version will be logged as below on server startup:
2014-12-18 09:08:43 0 [Note] /home/praveen/WorkDir/mysql_local/bug20052694/mysql-5.6/sql/mysqld (mysqld 5.6.23-debug-log) starting as process 18474 ...
Description: The server fails write its version information to the error log until after it completes the startup cycle. Should there be any failure during startup, the log will have no record of which version failed to start. * This blocks proper troubleshooting activities. This is true especially during an upgrade failure, a dual execution scenario (the user starts up more than one mysqld against the same set of data+logs), and many other abnormal situations. * The server's version details are compiled in. This requires no external processing to generate. * A failure or crash in the code that initializes plugins (the current first entry in the error log) can result in no startup error log entries at all because the server crashed before the first entry could be flushed to disk. How to repeat: Read any error log. The first entry during a startup cycle is not a timestamped version code. example from a 5.6.11 server 2014-11-17 13:16:36 3932 [Note] Plugin 'FEDERATED' is disabled. Suggested fix: Add a patch to the code to include a timestamped entry stating which version is attempting to start. Here is one possible example: yymmdd HH:nn:ss (pid here) Starting MySQL Enterprise version x.xx.xx with (command line options here) This needs to appear in the error log file before any other actions are attempted. None of those details should require much processing to determine. The executable knows how it was called and the version is a compiled-in constant. This entry needs to happen as early in the startup cycle as possible to have the least chance of failure.