Skip navigation links
5.2.3 The General Query Log »
Section Navigation      [Toggle]

5.2.2. The Error Log

The error log contains information indicating when mysqld was started and stopped and also any critical errors that occur while the server is running. If mysqld notices a table that needs to be automatically checked or repaired, it writes a message to the error log.

On some operating systems, the error log contains a stack trace if mysqld dies. The trace can be used to determine where mysqld died. See MySQL Internals: Porting.

You can specify where mysqld writes the error log with the --log-error[=file_name] option. If no file_name value is given, mysqld uses the name host_name.err by default and writes the file in the data directory. If you execute FLUSH LOGS, the error log is renamed with the suffix -old and mysqld creates a new empty log file. (No renaming occurs if the --log-error option was not given to mysqld.)

If you do not specify --log-error, or (on Windows) if you use the --console option, errors are written to stderr, the standard error output. Usually this is your terminal.

On Windows, error output is always written to the .err file if --console is not given.

In addition, on Windows, events and error messages are written to the Windows Event Log within the Application log. Entries marked as Warning and Note are written to the Event Log, but informational messages (such as information statements from individual storage engines) are not copied to the Event Log. The log entries will have a source of MySQL. You cannot disable writing information to the Windows Event Log.

The --log-warnings option or log_warnings system variable can be used to control warning logging to the error log. The default value is enabled (1). Warning logging can be disabled using a value of 0. If the value is greater than 1, aborted connections are written to the error log. See Section B.1.2.11, “Communication Errors and Aborted Connections”.

If you use mysqld_safe to start mysqld, mysqld_safe arranges for mysqld to write error messages to a log file or (as of MySQL 5.1.20) to syslog:

  • Before 5.1.20, mysqld_safe behavior is to log to a file, using the default error log file if the --log-error option is not given to mysqld_safe. Otherwise, mysqld_safe uses the file name specified via --log-error=file_name.

  • From 5.1.20 on, mysqld_safe has two additional error-logging options, --syslog and --skip-syslog.

    In 5.1.21 and up, the default with no logging options is --skip-syslog, which is compatible with the default behavior of writing an error log file for releases prior to 5.1.20. To explicitly specify use of an error log file, specify --log-error=file_name to mysqld_safe, and mysqld_safe will arrange for mysqld to write messages to a log file. To use syslog instead, specify the --syslog option.

    In 5.1.20 only, the following conditions apply: 1) The default is to use syslog, which is not compatible with releases prior to 5.1.20. 2) Logging to syslog may fail to operate correctly in some cases; if so, use --skip-syslog or --log-error.

    For logging to syslog, messages from mysqld_safe and mysqld are written with a tag of mysqld_safe and mysqld, respectively. As of MySQL 5.1.21, to specify a suffix for the tag, use --syslog-tag=tag, which modifies the tags to be mysqld_safe-tag and mysqld-tag.

If you specify --log-error in an option file in a section that mysqld reads, mysqld_safe also will find and use the option.

If mysqld_safe is used to start mysqld and mysqld dies unexpectedly, mysqld_safe notices that it needs to restart mysqld and writes a restarted mysqld message to the error log.


User Comments

Posted by Jonathan Lampe on September 23 2004 1:20pm[Delete] [Edit]

I did some testing with MySQL 4.0.21 this morning. Here's a typical snippet from my "hostname.err" file. To generate this, I did a "NET START MySQL", connected with one session and ran a 2000-entry query, and then did a "NET STOP MySQL" while the query was still returning data.

MySql: ready for connections.
Version: '4.0.21-nt-log' socket: '' port: 3306 Source distribution
040923 10:00:00 MySql: Normal shutdown
040923 10:00:01 MySql: Forcing close of thread 1 user: 'root'
040923 10:00:01 InnoDB: Starting shutdown...
040923 10:00:03 InnoDB: Shutdown completed
040923 10:00:03 MySql: Shutdown Complete

The Windows Application Event Log recorded 3 messages at the same time. All of the messages corresponded with the entries prefixed with the "MySQL:" entries in the hostname.err file. (OK)

However, all 3 messages were logged as ERRORS; this designation is misleading. If anything, the "Normal Shutdown" and "Shutdown Complete" messages should have been logged as INFORMATION and the "Forcing close of thread..." message should have been logged as a WARNING.

Also, it is important to note that the MySQL service startup was NOT LOGGED in the Event Log.

Long story short, if you are a Windows user, it is probably still best (as of 4.0.21) to stick with your existing "parse-the-.err" script rather than rely on the Windows Event Log if you're interested in MySQL service starts, stops and abnormal events.

Posted by Steve Bacher on July 30 2008 1:51pm[Delete] [Edit]

It seems that if you are using mysqld_safe (whether you specify --log-error= or not), FLUSH LOGS will not rename and recreate the error log, because mysqld_safe does not pass the --log-error= arg to mysqld; rather, it runs mysqld with stderr redirected to the error log file.

Add your own comment.