Details

    Description

      Send SIGHUP, so root credentials are no longer needed to be set in a config file
      Update comments about configuration
      Enable creation of the log; when disabled, logrotate would fail (file not found) when ran twice on stopped daemon.

      Attachments

        Issue Links

          Activity

            mschorm Michal Schorm added a comment -

            Also, consider using of "delaycompress" option.

            Without it, the user may encounter an error if the DB still use the file handle to write to the log.

            /etc/cron.daily/logrotate:

            error: Compressing program wrote following message to stderr when compressing log /var/log/mariadb/mariadb.log-20190228:
            gzip: stdin: file size changed while zipping
            

            mschorm Michal Schorm added a comment - Also, consider using of "delaycompress" option. Without it, the user may encounter an error if the DB still use the file handle to write to the log. /etc/cron.daily/logrotate: error: Compressing program wrote following message to stderr when compressing log /var/log/mariadb/mariadb .log-20190228: gzip : stdin: file size changed while zipping
            GeoffMontee Geoff Montee (Inactive) added a comment - - edited

            Also, consider using of "delaycompress" option.

            Without it, the user may encounter an error if the DB still use the file handle to write to the log.

            Thanks. I used the "delaycompress" tip for this KB article:

            https://mariadb.com/kb/en/library/rotating-logs-on-unix-and-linux/

            Send SIGHUP, so root credentials are no longer needed to be set in a config file

            Is it still desirable to use SIGHUP to flush the logs, now that root@localhost will use unix_socket authentication by default in 10.4? i.e. see MDEV-12484.

            It's pretty easy to enable unix_socket authentication for root@localhost in earlier versions too.

            danblack mentioned that SIGHUP will have the side effect of also flushing the binlogs, which can have a performance penalty. Should we make SIGHUP ignore exclude flushing the binlogs?

            GeoffMontee Geoff Montee (Inactive) added a comment - - edited Also, consider using of "delaycompress" option. Without it, the user may encounter an error if the DB still use the file handle to write to the log. Thanks. I used the "delaycompress" tip for this KB article: https://mariadb.com/kb/en/library/rotating-logs-on-unix-and-linux/ Send SIGHUP, so root credentials are no longer needed to be set in a config file Is it still desirable to use SIGHUP to flush the logs, now that root@localhost will use unix_socket authentication by default in 10.4? i.e. see MDEV-12484 . It's pretty easy to enable unix_socket authentication for root@localhost in earlier versions too. danblack mentioned that SIGHUP will have the side effect of also flushing the binlogs, which can have a performance penalty. Should we make SIGHUP ignore exclude flushing the binlogs?
            danblack Daniel Black added a comment -

            With the multiple authentication mechanisms of MDEV-11340 and the default root unix socket auth in MDEV-12484, and in 65ffea3924f8d90bce5ae5188d5b44feaaaf6c7f, mysql@localhost unix socket is a default user on install. If adding/extending the auth was done in packaging scripts, maybe 'sudo -u mysql /usr/bin/mysqladmin --user mysql ....`. I discovered 'su mysql mysql' in logrotate doesn't impact scripts.

            > Should we make SIGHUP ignore exclude flushing the binlogs?

            There are more impacts than binlogs (https://github.com/MariaDB/server/blob/10.4/sql/mysqld.cc#L3289-L3293) that could be reduced. Not sure if anything expects this behaviour. Maybe a different signal (USR1?) if the authentication mechanisms aren't sufficient.

            Very nice work GeoffMontee on the kb document. Note selinux bits of logrotate from https://mariadb.com/kb/en/library/what-to-do-if-mariadb-doesnt-start/#selinux-and-mariadb-path-changes and/or extend support-files/policy/selinux/mariadb-server.fc

            danblack Daniel Black added a comment - With the multiple authentication mechanisms of MDEV-11340 and the default root unix socket auth in MDEV-12484 , and in 65ffea3924f8d90bce5ae5188d5b44feaaaf6c7f, mysql@localhost unix socket is a default user on install. If adding/extending the auth was done in packaging scripts, maybe 'sudo -u mysql /usr/bin/mysqladmin --user mysql ....`. I discovered 'su mysql mysql' in logrotate doesn't impact scripts. > Should we make SIGHUP ignore exclude flushing the binlogs? There are more impacts than binlogs ( https://github.com/MariaDB/server/blob/10.4/sql/mysqld.cc#L3289-L3293 ) that could be reduced. Not sure if anything expects this behaviour. Maybe a different signal (USR1?) if the authentication mechanisms aren't sufficient. Very nice work GeoffMontee on the kb document. Note selinux bits of logrotate from https://mariadb.com/kb/en/library/what-to-do-if-mariadb-doesnt-start/#selinux-and-mariadb-path-changes and/or extend support-files/policy/selinux/mariadb-server.fc

            Thanks, danblack. I added a note about SELinux to the logrotate KB page.

            GeoffMontee Geoff Montee (Inactive) added a comment - Thanks, danblack . I added a note about SELinux to the logrotate KB page.
            otto Otto Kekäläinen added a comment - Superseded by https://github.com/MariaDB/server/pull/1556 and MDEV-22659 .
            robertbindar Robert Bindar added a comment -

            Closing this dangling one, work on logrotate is being followed in MDEV-22659

            robertbindar Robert Bindar added a comment - Closing this dangling one, work on logrotate is being followed in MDEV-22659

            People

              otto Otto Kekäläinen
              svoj Sergey Vojtovich
              Votes:
              1 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.