rpms/mariadb
7
0
Fork 0
Code Issues Pull Requests Releases Activity

[2/2] Rebase to 10.11.6 - start using upstream logrotate file

Browse Source 
Explanation for removed notes follow:

| * Enable creation of the log file by logrotate (needed since
|   /var/log/ isn't writable by mysql user); and set the same 640
|   permissions we normally use.

This is an ancient artefact.
It originates in this commit from 2012 in the 'mysql' package in Fedora:
  https://src.fedoraproject.org/rpms/mysql/c/d3bdaa4a?branch=rawhide
That was at the time, when the DB log resided directly in '/var/log/', rather than '/var/log/some-dir-specific-for-the-DB/'.
Since that is no longer the case, the 'create 600 mysql mysql' directive is no longer necessary.

| * Comment out the actual rotation commands, so that user must edit
|   the file to enable rotation.  This is unfortunate, but the fact
|   that the script will probably fail without manual configuration
|   (to set a root password) means that we can't really have it turned
|   on by default.  Fortunately, in most configurations the log file
|   is low-volume and so rotation is not critical functionality.

This is no longer true.
Since MariaDB 10.4, which introduced authentication via the UNIX socket,
the 'root' and 'mysql' users can authenticate without login and password.

So we can go back to using 'mysqladmin', or 'mariadb-admin' in this case, to flush logs

| See discussions at RH bugs 799735, 547007
| * Note they are from Fedora 15 / 16

I found no more useful information there. Only information already mentioned in other notes here.

| Update 3/2017
| * it would be big unexpected change for anyone upgrading, if we start shipping it now.
|  Maybe it is good candidate for shipping with MariaDB 10.2 ?

Introduction of MariaDB 10.11 is the perfect time.

| * the 'mysqladmin flush logs' doesn´t guarantee, no entries are lost
|   during flushing, the operation is not atomic.
|   We should not ship it in that state

True, however, no one likely cares about that, in reality, since those logs don't hold any journal-like entries.
Explained here:
  https://github.com/MariaDB/server/pull/1556#issuecomment-941886220

| Update 6/2018
| * the SIGHUP causes server to flush all logs. No password admin needed, the only constraint is
|   beeing able to send the SIGHUP to the process and read the mysqld pid file, which root can.
| * Submited as PR: https://github.com/MariaDB/server/pull/807

It has been dicussed on the upstream thoroughly and was found far from ideal.
Now, that we can use 'mysqladmin', or 'mariadb-admin' in this case, safely again,
there's no argument to keep using the PID file for flushing logs.

| Update 02/2021
| * Enhance the script as proposed in:
|   https://mariadb.com/kb/en/rotating-logs-on-unix-and-linux/

Enhanced again now. Significantly this time, however with a vision that the values will become an OS-independent defaults.

|  * Discussion continues in:
|   https://jira.mariadb.org/browse/MDEV-16621

Discussion finished.
Better start a new one, if needed.
This commit is contained in:
Michal Schorm 2023-12-18 06:44:39 +01:00
parent 6f385ec682
commit 670c3889f6
2 changed files with 27 additions and 82 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

102
mariadb-logrotate.patch
View File

@ -1,82 +1,32 @@
Adjust the mysql-log-rotate script in several ways:
Adjust the 'mariadb.logrotate.sh' script in several ways:
* Use the correct log file pathname for Red Hat installations.
* Enable creation of the log file by logrotate (needed since
/var/log/ isn't writable by mysql user); and set the same 640
permissions we normally use.
* Comment out the actual rotation commands, so that user must edit
the file to enable rotation. This is unfortunate, but the fact
that the script will probably fail without manual configuration
(to set a root password) means that we can't really have it turned
on by default. Fortunately, in most configurations the log file
is low-volume and so rotation is not critical functionality.
See discussions at RH bugs 799735, 547007
* Note they are from Fedora 15 / 16
* Remove Debian specific code
for the very unlikely, but possible scenario
in which the debian config file would exist.
Update 3/2017
* it would be big unexpected change for anyone upgrading, if we start shipping it now.
Maybe it is good candidate for shipping with MariaDB 10.2 ?
* the 'mysqladmin flush logs' doesn´t guarantee, no entries are lost
during flushing, the operation is not atomic.
We should not ship it in that state
Update 6/2018
* the SIGHUP causes server to flush all logs. No password admin needed, the only constraint is
beeing able to send the SIGHUP to the process and read the mysqld pid file, which root can.
* Submited as PR: https://github.com/MariaDB/server/pull/807
Update 02/2021
* Enhance the script as proposed in:
https://mariadb.com/kb/en/rotating-logs-on-unix-and-linux/
* Discussion continues in:
https://jira.mariadb.org/browse/MDEV-16621
--- mariadb-10.5.13-downstream_modified/support-files/mysql-log-rotate.sh 2022-02-22 04:56:35.571185622 +0100
+++ mariadb-10.5.13-downstream_modified/support-files/mysql-log-rotate.sh_patched 2022-02-22 04:56:15.121003580 +0100
@@ -3,36 +3,23 @@
# in the [mysqld] section as follows:
#
# [mysqld]
-# log-error=@localstatedir@/mysqld.log
-#
-# If the root user has a password you have to create a
-# /root/.my.cnf configuration file with the following
-# content:
-#
-# [mysqladmin]
-# password = <secret>
-# user= root
-#
-# where "<secret>" is the password.
-#
-# ATTENTION: This /root/.my.cnf should be readable ONLY
-# for root !
+# log-error=@LOG_LOCATION@
--- mariadb-10.11.6/support-files/mariadb.logrotate.sh 2023-11-08 16:51:43.000000000 +0100
+++ mariadb-10.11.6/support-files/mariadb.logrotate.sh_patched 2023-12-17 18:03:36.955861025 +0100
@@ -6,7 +6,7 @@
# Read https://mariadb.com/kb/en/error-log/ to learn more about logging and
# https://mariadb.com/kb/en/rotating-logs-on-unix-and-linux/ about rotating logs.
-@localstatedir@/mysqld.log {
- # create 600 mysql mysql
-@localstatedir@/mysqld.log @localstatedir@/mariadb.log @logdir@/*.log {
+@LOG_LOCATION@ {
+ create 600 mysql mysql
su mysql mysql
notifempty
daily
rotate 3
missingok
compress
+ delaycompress
+ sharedscripts
postrotate
# just if mariadbd is really running
- if test -x @bindir@/mysqladmin && \
- @bindir@/mysqladmin ping &>/dev/null
- then
- @bindir@/mysqladmin --local flush-error-log \
- flush-engine-log flush-general-log flush-slow-log
- fi
+ if [ -e @PID_FILE_DIR@/@DAEMON_NO_PREFIX@.pid ]
+ then
+ kill -1 $(<@PID_FILE_DIR@/@DAEMON_NO_PREFIX@.pid)
+ fi
endscript
}
# Depends on a mysql@localhost unix_socket authenticated user with RELOAD privilege
@su_user@
@@ -45,11 +45,6 @@
# 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 @bindir@/mariadb-admin
then
@bindir@/mariadb-admin $EXTRAPARAM --local flush-error-log \

7
mariadb.spec
View File

@ -1013,11 +1013,6 @@ rm %{buildroot}%{_mandir}/man1/mytop.1*
# Should be shipped with mariadb-connector-c
rm %{buildroot}%{_mandir}/man1/mariadb_config.1*
# put logrotate script where it needs to be
mkdir -p %{buildroot}%{logrotateddir}
mv %{buildroot}%{_datadir}/%{pkg_name}/mysql-log-rotate %{buildroot}%{logrotateddir}/%{daemon_name}
chmod 644 %{buildroot}%{logrotateddir}/%{daemon_name}
# for compatibility with upstream RPMs, create mysqld symlink in sbin
mkdir -p %{buildroot}%{_sbindir}
ln -s %{_libexecdir}/mysqld %{buildroot}%{_sbindir}/mysqld
@ -1047,7 +1042,7 @@ touch %{buildroot}%{_sysconfdir}/sysconfig/clustercheck
install -p -m 0755 %{_vpath_builddir}/scripts/clustercheck %{buildroot}%{_bindir}/clustercheck
# remove duplicate logrotate script
rm %{buildroot}%{logrotateddir}/mysql
rm %{buildroot}%{_datadir}/mariadb/mariadb.logrotate
# Remove AppArmor files
rm -r %{buildroot}%{_datadir}/%{pkg_name}/policy/apparmor