Bug #41602 log_warnings sends abborted connects to general log not error log
Submitted: 18 Dec 2008 20:26 Modified: 12 Feb 2009 17:58
Reporter: Tom Hanlon Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: General Severity:S3 (Non-critical)
Version:5.0.74, 5.1.30-community-log MySQL Community Se OS:Windows
Assigned to: Paul DuBois CPU Architecture:Any

[18 Dec 2008 20:26] Tom Hanlon 
Description:
The documentation states in section 5.2.2:

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”. 

When I enable log_warnings on my machine I get the aborted connect attempts to my general log and not my error log. 

TEE==>show variables like "%warning%";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_warnings  | 2     |
| sql_warnings  | OFF   |
| warning_count | 0     |
+---------------+-------+
3 rows in set (0.00 sec)

My _general_ log..

12:18:27    6 Connect	root@localhost on world
		    6 Query	SET NAMES utf8
081218 12:18:55    7 Connect	Access denied for user 'root'@'localhost' (using password: YES)
081218 12:18:56    8 Connect	Access denied for user 'root'@'localhost' (using password: YES)
		    9 Connect	Access denied for user 'root'@'localhost' (using password: YES)

My Error log does not have the aborted connects

How to repeat:
Turn on general log

Enable log_warnings

Try some aborted conections, failed passwords. 

Read the logs.

Suggested fix:
Since abborted connects combined with tailing your log files is one way to try and detect brute-force password hacks then this is not trivial. This should be in the error log, enabling the general log is not a solution. 

Of course the documentation is wrong, or the server has a bug, or it is a windows only bug. If windows only then fix the docs, if linux bug also then send the abborted connects to the error log.
[19 Dec 2008 4:33] Valeriy Kravchuk 
Thank you for a problem report. Verified just as described.
[19 Dec 2008 4:43] Valeriy Kravchuk 
Linux is also affected. If this is intended (?), then documentation should be changed.
[11 Feb 2009 14:52] Staale Smedseng 
The documentation given in "B.1.2.11. Communication Errors and Aborted Connections" is slightly ambiguous: Only the three first cases specified (i.e., the three first bullets) will generate messages to the error log (of the kind shown in the example error log), and only so if log_warnings is set appropriately. As it is, this error only applies to abnormal termination of connections that already exist, and not errors during connection setup and login attempts.

The four cases/bullets below regard connection setup and login, and may result in various error types, none of which are of the type specified in the example going to the error log. For now, the only way to monitor for attempted brute force attacks is through the general log.

You can however file this as a feature request.

Setting category to Documentation, requesting a clarification of this particular dichotomy.
[12 Feb 2009 17:58] Paul DuBois 
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant products.
[13 Mar 2009 3:57] MySQL Verification Team 
IMHO logging aborted connections to general log is useless in production environment where general log is hardly to be switched on. It is very important to record such login failures in order to detect unauthorized login attempts.

Why don't we increase the priority for this bug?