Force MariaDB error logs to have read permissions when created
I recently became aware of this SQL query for MariaDB:
SHOW GLOBAL VARIABLES LIKE 'log_error';
In turn I updated my internal system logs page. In part because cPanel splits the logs up in to a file per day. That's fine, I updated my code.
The problem is that every day when a new log is created it's created with CHMOD 640 instead of 644. PHP doesn't use the root user which is fine. However I want to avoid having to change my FTP user to root, manually connect to the FTP, break synchronous browsing, change the remote directory, hunt down all of the new error log files and manually change their CHMOD to 644.
Example directory/file list:
- /var/log/mysql.error.log
- /var/log/mysql.error.log-20250716
- /var/log/mysql.error.log-20250717
- /var/log/mysql.error.log-20250718
- /var/log/mysql.error.log-20250719
I can't change the permissions using the Linux user that PHP uses which is fine. So ultimately: how do I change cPanel to create the error logs with a 644 CHMOD? This would dramatically streamline my operations when being proactive and making sure there isn't any funny business going on. No: I don't have time to add extra steps just to look at log files and no, I explicitly do not want to live in the Linux terminal. I need to get things done to help businesses and people and the terminal, while very capable, it a major blow to efficiency.
-
Hey hey! This is one where I just reject the premise :D - a default cPanel installation doesn't create those unique daily log files. Actually, can you share the output of the
SHOW GLOBAL VARIABLES LIKE 'log_error';command you posted? I'm expecting to see this:
[root@host /]# mysql -e "SHOW GLOBAL VARIABLES LIKE 'log_error';"
+---------------+---------------------+
| Variable_name | Value |
+---------------+---------------------+
| log_error | /var/log/mysqld.log |
+---------------+---------------------+I'm gonna state this again for dramatic effect: I haven't seen a cPanel server create such a log file with a new log for each day for the MySQL service, so it seems like something else is happening on this particular system.
0 -
Hi Rex! Thank you for your response! They need to pay you extra!
So a search for "mariadb error log per day" (without quotes) led me to a comment here:
https://stackoverflow.com/questions/42685888/mysql-logs-per-dayThat comment led me to this answer:
https://stackoverflow.com/questions/4601658/rotating-mysql-slow-query-log#answer-4601676Which led me to this page for confirmation:
https://cloudlinux.zendesk.com/hc/en-us/articles/360002508674-Duplicate-log-entry-for-var-lib-mysql-mysqld-logBy pure chance, that last page mentions CloudLinux which is the Linux distribution that replaced the previous Linux distribution my web host was using.
Any way, so it looked like the commend "
logrotate" was what I was possibly looking for so I brought up PuTTY and ran the following command:grep -r "logrotate" / -sThere was over 50 entries returned and pasting the results in to Notepad++ I quickly found the following line:
/etc/logrotate.d/mariadb:# This is the MariaDB configuration for the logrotate utility
So, I suppose I need to think about this one. I don't know if I've posted anything around the CloudLinux forums (or if they have forums). So maybe if I simply removing the file it won't be automatically repopulated or maybe it will? In either case, perhaps, if they have a forum, someone there will be as helpful with this problem as you have been with the threads I've posted here in the past. Hopefully the string of actions I've posted will help others realize how easy it is to do a little research. 🙂︀
0 -
When I checked both a CloudLinux and AlmaLinux 9 system with MariaDB installed, I'm not seeing anything obvious in the /etc/logrotate.d/mariadb file that would make multiples. The default shows that it keeps 6 months of logs and rotates the file when it reaches 500M. If the filesize is less than 50M, it doesn't rotate at all.
# Run monthly
monthly
# Keep 6 months of logs
rotate 6
# If file is growing too big, rotate immediately
maxsize 500M
# If file size is too small, don't rotate at all
minsize 50Mso that still wouldn't explain these daily ones you're seeing unless your logrotate file has been customized in some way.
0 -
Okay, so here are the contents of the two relevant files:
/etc/logrotate.d/mariadb
/var/lib/mysql/mysqld.log /var/lib/mysql/mariadb.log /var/log/mariadb/*.log { # Depends on a mysql@localhost unix_socket authenticated user with RELOAD privilege su mysql mysql # If any of the files listed above is missing, skip them silently without # emitting any errors missingok # If file exists but is empty, don't rotate it notifempty # Run monthly monthly # Keep 6 months of logs rotate 6 # If file is growing too big, rotate immediately maxsize 500M # If file size is too small, don't rotate at all minsize 50M # Compress logs, as they are text and compression will save a lot of disk space compress # Don't compress the log immediately to avoid errors about "file size changed while zipping" delaycompress # Don't run the postrotate script for each file configured in this file, but # run it only once if one or more files were rotated sharedscripts # After each rotation, run this custom script to flush the logs. Note that # this assumes that the mariadb-admin command has database access, which it # has thanks to the default use of Unix socket authentication for the 'mysql' # (or root on Debian) account used everywhere since MariaDB 10.4. postrotate if test -r /etc/mysql/debian.cnf then EXTRAPARAM='--defaults-file=/etc/mysql/debian.cnf' fi if test -x /usr/bin/mariadb-admin then /usr/bin/mariadb-admin $EXTRAPARAM --local flush-error-log \ flush-engine-log flush-general-log flush-slow-log fi endscript }/etc/logrotate.d/mariadb
/var/log/mysql.error.log { create 644 mysql root notifempty daily rotate 5 missingok nocompress nocopytruncate dateext sharedscripts postrotate env HOME=/root/ /usr/bin/mysql -e 'flush logs' endscriptI just changed the 640 to 644 in the second file and since it's daily I'll just wait until tomorrow to confirm that worked.
0
Please sign in to leave a comment.
Comments
4 comments