MySQL Bugs: #19642: FLUSH LOGS does not recreate a new empty error log files

Bug #19642	FLUSH LOGS does not recreate a new empty error log files
Submitted:	9 May 2006 16:32	Modified:	27 Jul 2006 5:18
Reporter:	dominique Bouillet	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	5.0.23-BK, 5.0.21	OS:	Linux (Linux, Sun Solaris 8)
Assigned to:		CPU Architecture:	Any

Description:
I have started mysqld that way:

./bin/mysqld_safe --socket=/tmp/mysql_default.lock --skip-networking --datadir=/OT/data/mysql/default --log-error=/OT/logs/mysql/default/error.log

in the mysql home directory, the .my.cnf contains the following options:
[mysqld]
skip-networking
skip-name-resolve
myisam-recover
innodb_file_per_table

As explained in reference manual (section 13.5.5.2), I am flushing logs using the command FLUSH LOGS, in mysql command line tool. 
I am expecting to have my error.log file renamed and a new one created, but nothing happens.

How to repeat:
launch mysqld with the same options as I did.

in mysql type FLUSH LOGS.

check that the error log has been renamed.

Suggested fix:
implement as specified in the reference manual.

Thank you for the bug report. I was unable to reproduce on Linux:

miguel@hegel:~/dbs/5.0> ls /home/miguel/dbs/OT/myerr* -la
-rw-rw----  1 miguel users   0 2006-05-11 14:09 /home/miguel/dbs/OT/myerror.log
-rw-rw----  1 miguel users 206 2006-05-11 14:09 /home/miguel/dbs/OT/myerror.log-old

Could you please verify if exist a file with -old suffix?

Thanks in advance.

Thanks for you reply. The -old file is not created.

No news on that topic?

I asked to a coworker for to test on Solaris box, since I was unable
to repeat on Linux.

I was able to verify this bug on Linux with 5.0.23-BK:

openxs@suse:~/dbs/5.0> bin/mysqld_safe --log-error=/tmp/error.log &
[1] 7716
openxs@suse:~/dbs/5.0> Starting mysqld daemon with databases from /home/openxs/dbs/5.0/var
openxs@suse:~/dbs/5.0> bin/mysql -uroot test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.0.23

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> select * from tttt;
ERROR 1146 (42S02): Table 'test.tttt' doesn't exist
mysql> flush logs;
Query OK, 0 rows affected (0.03 sec)

mysql> flush logs;
Query OK, 0 rows affected (0.01 sec)

mysql> exit
Bye
openxs@suse:~/dbs/5.0> ls -l /tmp/error*
-rw-rw----  1 openxs users 497 2006-06-13 14:26 /tmp/error.log
openxs@suse:~/dbs/5.0> cat /tmp/error.log
060613 14:26:30  mysqld started
060613 14:26:30  InnoDB: Started; log sequence number 0 1029074649
060613 14:26:30 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--relay-log=suse-relay-bin' to avoid this problem.
060613 14:26:30 [Note] /home/openxs/dbs/5.0/libexec/mysqld: ready for connections.
Version: '5.0.23'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
openxs@suse:~/dbs/5.0> bin/mysqladmin -uroot shutdown
STOPPING server from pid file /home/openxs/dbs/5.0/var/suse.pid
060613 14:27:49  mysqld ended

[1]+  Done                    bin/mysqld_safe --log-error=/tmp/error.log
openxs@suse:~/dbs/5.0> bin/mysqld_safe --log-error=`pwd`/error.log &
[1] 7757
openxs@suse:~/dbs/5.0> Starting mysqld daemon with databases from /home/openxs/dbs/5.0/var

openxs@suse:~/dbs/5.0> bin/mysql -uroot test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.0.23

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> flush logs;
Query OK, 0 rows affected (0.02 sec)

mysql> flush logs;
Query OK, 0 rows affected (0.01 sec)

mysql> exit
Bye
openxs@suse:~/dbs/5.0> ls -l error*
-rw-rw----  1 openxs users 497 2006-06-13 14:27 error.log
openxs@suse:~/dbs/5.0> bin/mysqladmin -uroot shutdown
STOPPING server from pid file /home/openxs/dbs/5.0/var/suse.pid
060613 14:28:24  mysqld ended

[1]+  Done                    bin/mysqld_safe --log-error=`pwd`/error.log

So, if error log is not in default location, it is not recreated upon FLUSH LOGS. When default one is used:

openxs@suse:~/dbs/5.0> bin/mysqld_safe --log-error &
[1] 7794
openxs@suse:~/dbs/5.0> Starting mysqld daemon with databases from /home/openxs/dbs/5.0/var

openxs@suse:~/dbs/5.0> bin/mysql -uroot test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.0.23

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> flush logs;
Query OK, 0 rows affected (0.01 sec)

mysql> flush logs;
Query OK, 0 rows affected (0.02 sec)

mysql> exit
Bye
openxs@suse:~/dbs/5.0> ls -l var/suse.err*
-rw-rw----  1 openxs users 0 2006-06-13 14:28 var/suse.err
-rw-rw----  1 openxs users 0 2006-06-13 14:28 var/suse.err-old

It works as described in http://dev.mysql.com/doc/refman/5.0/en/flush.html. 

It is a bug.

So as Kravchuk said, if we specify a paticular path for error-log which diff from the default one, use flush logs will not create the backup log. Does anyone can confirm this bug is fix or not in future release?

#I try to backup the log manually use "mv" 

> ls
error.log
> mv error.log error.old
> ls
error.old
>

#and flush logs

mysql> flush logs;
Query OK, 0 rows affected (0.00 sec)

# still just one old file there
> ls
error.old

# once the server encount a error. Such as try to start a already running server
#the error log is produced

> ls
error.log  error.old

So now what I want know is if I back up the log file mannualy just like using above, is it will take any unknow effect such as lost info?
can anyone help me?

Hello, all.

This is a duplicate of bug #6061.  Bug 6061 has been fixed in the 5.1 version only.  The reason for that was:

- The current (buggy) behavior has existed for a long time
- Minimize behavior changes in production releases

Also, the mysqld_safe from 5.1 can be used in 5.0 and earlier versions.

I hope this addresses the needs you have.

Regards,

Tim