Mysql error.log Empty - is this normal?

1

Just wondering if it’s normal to have a completely empty MySQL error.log file?

I thought it may have just been a slow day, but it appears to always be empty. I haven’t seen anything written to that file for weeks and the logrotate gz files are also empty.

The log file is here: /var/log/mysql/error.log

Looking at the mariadb config file from the HestiaCP (it uses this file: /etc/mysql/my.cnf) I can see the following line in that file:
log_error=/var/log/mysql/error.log

So as far as I can tell, I’m checking the correct log file, and that log file is empty, and the archived logrotate files are also showing empty.

Do I have some issue with the configuration for the log files or is it really running with 0 errors.

I waited for a while before posting this question, hoping to see some activity in those logs, but after several weeks, still empty.

Working as expected? Or anyway I can trigger an error to confirm it’s writing it?

2

Just checked my log file because I was updating some servers, I got logs while restart the mysql service:

2021-05-11 22:37:27 0 [Note] InnoDB: Using Linux native AIO
2021-05-11 22:37:27 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2021-05-11 22:37:27 0 [Note] InnoDB: Uses event mutexes
2021-05-11 22:37:27 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2021-05-11 22:37:27 0 [Note] InnoDB: Number of pools: 1
2021-05-11 22:37:27 0 [Note] InnoDB: Using SSE2 crc32 instructions
2021-05-11 22:37:27 0 [Note] mysqld: O_TMPFILE is not supported on /tmp (disabling future attempts)
2021-05-11 22:37:27 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2021-05-11 22:37:27 0 [Note] InnoDB: Completed initialization of buffer pool
2021-05-11 22:37:27 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2021-05-11 22:37:27 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2021-05-11 22:37:27 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2021-05-11 22:37:27 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2021-05-11 22:37:27 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2021-05-11 22:37:27 0 [Note] InnoDB: Waiting for purge to start
2021-05-11 22:37:27 0 [Note] InnoDB: 10.4.19 started; log sequence number 92803587471; transaction id 107773250
2021-05-11 22:37:27 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2021-05-11 22:37:27 0 [Note] Plugin 'FEEDBACK' is disabled.
2021-05-11 22:37:27 0 [Note] Server socket created on IP: '::'.
2021-05-11 22:37:27 0 [Note] Reading of all Master_info entries succeeded
2021-05-11 22:37:27 0 [Note] Added new Master_info '' to hash table
2021-05-11 22:37:27 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.4.19-MariaDB-1:10.4.19+maria~bionic'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
2021-05-11 22:37:28 0 [Note] InnoDB: Buffer pool(s) load completed at 210511 22:37:28

So maybe a running mysql service? What’s your OS?

1 Like
3

For additional information:

I confirmed that the config file is definitely the correct one as adding the below two lines to the config file resulted in the mysql.log file being created and updated. So that’s at least working.

general_log_file=/var/log/mysql/mysql.log
general_log=1

4

Interesting. If I restart the mysql service using “service mysql restart” I still see nothing in the error log.

I’m running Ubuntu 20.04 with a fresh install using HestiaCP installer from about 6 weeks ago.

5

Not able to reproduce, just checked on our main hestia server which runs ubuntu 20.04 aswell and has just go some updates:

root@xxxxxx:~# cat /var/log/mysql/error.log
2021-05-11 22:33:51 0 [Note] InnoDB: Using Linux native AIO
2021-05-11 22:33:51 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2021-05-11 22:33:51 0 [Note] InnoDB: Uses event mutexes
2021-05-11 22:33:51 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2021-05-11 22:33:51 0 [Note] InnoDB: Number of pools: 1
2021-05-11 22:33:51 0 [Note] InnoDB: Using SSE2 crc32 instructions
2021-05-11 22:33:51 0 [Note] mysqld: O_TMPFILE is not supported on /tmp (disabling future attempts)
2021-05-11 22:33:51 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2021-05-11 22:33:51 0 [Note] InnoDB: Completed initialization of buffer pool
2021-05-11 22:33:51 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2021-05-11 22:33:51 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2021-05-11 22:33:51 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2021-05-11 22:33:51 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2021-05-11 22:33:52 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2021-05-11 22:33:52 0 [Note] InnoDB: Waiting for purge to start
2021-05-11 22:33:52 0 [Note] InnoDB: 10.4.19 started; log sequence number 203864253; transaction id 294487
2021-05-11 22:33:52 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2021-05-11 22:33:52 0 [Note] Plugin 'FEEDBACK' is disabled.
2021-05-11 22:33:52 0 [Note] Server socket created on IP: '::'.
2021-05-11 22:33:52 0 [Note] Reading of all Master_info entries succeeded
2021-05-11 22:33:52 0 [Note] Added new Master_info '' to hash table
2021-05-11 22:33:52 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.4.19-MariaDB-1:10.4.19+maria~bionic'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
2021-05-11 22:33:52 0 [Note] InnoDB: Buffer pool(s) load completed at 210511 22:33:52

Can’t find any issue here, one server is ubuntu 18.04 (Proxmox LXC), the other is a Hetzner Cloud VM using ubuntu 20.04. Not able to reproduce here.

6

Thanks @Raphael

I’m Sorry! I spoke too quick. Restarting mysql service does result in messages being written to error log. I get similiar messages to what you posted above. So it is working!

Hmm, very strange, so I guess it’s working properly. So it’s normal to not have any errors written to the log for a day or so? I wouldn’t have thought so, but that’s great!

7

Yup is normal, also infact port 3306 is closed from outside, there is usualy not much to log.

1 Like
8

Nice! Yeah, I guess I’m so used to seeing so much noise in the apache logs, that I just assumed I would see at least something in these mysql logs. I have a quickly cron job that sends me an email with the last 50 lines of the mysql, apache error log files, mailqueue, and syslog.

I just started thinking why is the mysql one always blank. :wink:

Thanks for clearing that up for me. And that’s great news. One less thing to think about.

Note to self: Update my Bash Script to remind me → this log often empty, enjoy the quiteness. :wink:

9

@Raphael - btw, thanks for the quick response. You, Falzo and Eris are awesome. Deeply appreciate the work you guys do and the help you provide.

Things have been quite nice with the new HestiaCP. I think the last open issue I have is the open_basedir & phpmyadmin issue being reported in the apache logs (/var/log/apache2/error.log). Eris mentioned this is a known issue and something that would be addressed in the 1.4 release.

I was wondering if there is an easy fix for that issue that I could deploy in the meantime.

10

You may solve the empty logfile issue with this command:

echo “I am not empty now” > /var/log/mysql/error.log

11

haha, I like it. Sysadmin humor. I would go with this though:

echo “Nothing here but me…enjoy the silence” > /var/log/mysql/error.log

However, I would need to setup a cronjob to run that line every few days, as logrotate will archive the error.log and I will have a new empty one. :wink:

12

Or just fix permissions.

13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.