[MDEV-9140] log_error variable not used after upgrade from mysql 5.6 Created: 2015-11-17  Updated: 2015-11-20  Resolved: 2015-11-20

Status: Closed
Project: MariaDB Server
Component/s: Platform Debian
Affects Version/s: 10.1.8
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Jonas Krauss Assignee: Unassigned
Resolution: Not a Bug Votes: 0
Labels: need_feedback
Environment:

Ubuntu 12.04.5 LTS


Issue Links:
Blocks
blocks MDEV-8009 sql_error_log_dir or generic error_lo... Closed
blocks MDEV-8374 Debian: mysqld_safe Can't log to erro... Closed

 Description   

Performed a simple upgrade from mysql 5.6 via apt-get on Ubuntu 12.04. Everything worked so far (had to run mysql_upgrade manually though). However, logging is only done to syslog, even though I explicit set variable log_error in my.cnf. Looking at the status output during runtime shows that the variable is empty - seems it is ignored during startup (however other variables from the same my.cnf are working correctly).

For some reason the mysqld_safe script runs with option --skip-log-error, I see that when examining the running process. Looking through the startup script in init.d and mysqld_safe itself I could not locate where this comes from unfortunately.

From reading through the relevant articles on mariadb.com regarding logging etc. this looks like a bug to me. A search on stack overflow showed some users having similar issues:

http://stackoverflow.com/questions/31430086/cant-get-logging-to-work-on-mariadb
http://stackoverflow.com/questions/17741974/mariadb-log-error-variable



 Comments   
Comment by Elena Stepanova [ 2015-11-19 ]

There might be a config file /etc/my.cnf.d/mysqld_safe_syslog.conf, please check if you have it (and comment the syslog option if it's there).

Comment by Jonas Krauss [ 2015-11-20 ]

Thanks for looking into this.

I just had a look at the folder /etc/mysql and found the file you mentioned in /etc/mysql/conf.d/mysqld_safe_syslog.cnf

It just contained the two lines for skipping the error log and instead using syslog. Commented them out, now it works.

I suggest to always priorize properties from the my.cnf in /etc/mysql to avoid this kind of confusion anyways.

Comment by Elena Stepanova [ 2015-11-20 ]

There is no hidden logic in priorities which could be changed this way. Your my.cnf contains an include directive at the end, so the included files are effectively appended to the end of the file, and naturally the later occurrences of options override the earlier ones. If you want contents of your my.cnf to have priority over the additional ones, you'll need to move include to the beginning of the file.

Generated at Thu Feb 08 07:32:26 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.