Setting MariaDB CHMOD to 644, removing logrotate properly + anything else?

[JAB Creations]

I need the Linux user that PHP uses to have access to the MariaDB error log so that way I can review it for a few seconds every few days. If the CHMOD is changed by sometime in the system then I have to manually go back through a long list of technical things to re-CHMOD it from 640 to 644.

So I discovered the following query which eventually led me to finding out the Barnum & Bailey and hackers were brute-force guessing pass words on my personal desktop. So I changed the port and restricted the IP addresses, problem solved. That being said, I want to be vigilant by keeping tabs on various system logs on my live server (which is not my desktop) in my web based system by clicking a couple links. Way easier than SSH, FTP, CHMOD, etc.

Going back to the start, I recently became aware of this SQL query for MariaDB:

SHOW GLOBAL VARIABLES LIKE 'log_error';

That in turn revealed the MariaDB error log is located at /var/log/mysql.error.log. However, both cPanel and CloudLinux have a lot of, complications. So I go to the directory with my FTP and see the following relevant files:

• /var/log/mysql.error.log-20250716
• /var/log/mysql.error.log-20250717
• /var/log/mysql.error.log-20250718
• /var/log/mysql.error.log-20250719

Okay, so something is splitting the files and that has a lot of valid use-cases which is fine for other people. But for me, that means a Linux user (that PHP isn't being run as) is setting the CHMOD to 640 when I need it to be 644 for my Linux user that PHP uses to be able to access the file and streamline my security duties.

So I did a search for "mariadb error log per day" (without the quotes) and after a bit of browsing I came across the logrotate command. So I ran the following command in PuTTY/SSH:

grep -r "logrotate" / -s​

I copied the results to Notepad++ and quickly found the following from the 50+ lines:

/etc/logrotate.d/mariadb:# This is the MariaDB configuration for the logrotate utility

Okay, this looks about as relevant as it's going to get as I'm not a server administrator.

Now, I know enough about Linux that I can generally get around, okay, like a 3/10 skill wise. So I've got the experience to know that if I delete that file that there is a 50/50 chance that something will automatically regenerate it and thus restore the rotation of the log file and thus the CHMOD will get changed back from 644 (good) to 640 (bad).

So, with all of that context in mind: how do I ensure that when I change the CHMOD of /var/log/mysql.error.log to 644 that it stays CHMO 644 until the end of all eternity? Is it a command I need to execute for logrotate? Can I simply download a copy of the file logrotate.d/mariadb file and then delete it from the server and not have to be concerned with it ever again? Is there something entirely different that is actually handling or doing even more stuff with the log? Thank you in advance for any time used to provide help.

[JAB Creations]

The file /etc/logrotate.d/mysqld did not have a properly close }, fixing that alone resulted in today's dated log file being correctly created using 644 for permissions.

[bogdan.sh]

Hello there!

You are right at your assumptions of something to recreate it, and yes it us logrotate for sure. Depending on OS versions it could be kinda different, but generally you need the /etc/logrotate.d/mysql file. All the rules of what is done before/after rotation and how the file is created are specified there, and you would have to look for something like:

create 640 mysql mysql

Just set the correct mode and you should be good.

[JAB Creations]

Hello there!

You are right at your assumptions of something to recreate it, and yes it us logrotate for sure. Depending on OS versions it could be kinda different, but generally you need the /etc/logrotate.d/mysql file. All the rules of what is done before/after rotation and how the file is created are specified there, and you would have to look for something like:

create 640 mysql mysql

Just set the correct mode and you should be good.

Hi, thank you for taking the time to reply. I am not a Linux expert, please do not presume I inherently know various contexts. So this is what is in the mariadb file:

/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
}​

Which means there are likely multiple MariaDB log files or it's trying to cover every known possibility?

Any way this page (create 660 mysql mysql) suggested that create is part of a terminal command, not the configuration file. So you've completely lost me on what to do with a create command? In fact, where is the logrotate executable to begin with along with proper documentation?

So there is also a mysqld file with the following contents:

/var/log/mysql.error.log {
create 640 mysql root
notifempty
daily
rotate 5
missingok
nocompress
nocopytruncate
dateext
sharedscripts
postrotate
env HOME=/root/ /usr/bin/mysql -e 'flush logs'
endscript​

Now, in there, I obviously changed the 640 to 644 and will give it ~24 hours before checking on the next generated log file. Maybe it'll be that simple, I'm not sure. So I don't know if this resolves it or not, time will tell. Thank you for taking the time to help.

[JAB Creations]

The file /etc/logrotate.d/mysqld did not have a properly close }, fixing that alone resulted in today's dated log file being correctly created using 644 for permissions.