On 30/03/17 20:46, Matthew Pash wrote:
> Morning Daniel,
>
> Thanks for your reply, I've been doing some more testing.  The logrotate
> script (below) currently runs fine when executed manually (sudo
> logrotate -v -f /etc/logrotate.d/mysql) but fails when run overnight by
> cron.
>
> /var/log/mysqld.log {
>   compress
>   daily
>   missingok
>   notifempty
>   rotate 3
>   postrotate
>     if test -x /usr/bin/mysqladmin && /usr/bin/mysqladmin ping &>/dev/null
>     then
>     /usr/bin/mysqladmin flush-logs
>     fi
>   endscript
> }
>
> I tweaked it last night to capture the output of the mysqladmin command
> and it did this:
>
> /usr/bin/mysqladmin: connect to server at 'localhost' failed
> error: 'Access denied for user 'root'@'localhost' (using password: NO)'
>
> Which makes me think the problem is more about cron than MariaDB.

No, MariaDB doesn't have a passwordless root user that mysqladmin needs
to issue the flush-logs command.

I suspect that there was originally a root user with socket
authentication this system.

Even after fixing this the mysqld may not be able to create new logs in
/var/log/. I'd normally expect /var/log/mysql to be owned by the mysql
user and its configuration to log the error to a file in this directory.

>  I've
> added some extra information gathering, so we'll see how it runs tonight.
>
>
> On 27 March 2017 at 22:34, Daniel Black <daniel.black@au1.ibm.com

> <mailto:daniel.black@au1.ibm.com>> wrote:
>
>     I think you'll find that the mysql user don't have permissions to create
>     a new file in /var/log/. As such logrotate renames the file which is
>     still open by mysqld. As such it is now writing to mysqld.log.1.
>
>     On 28/03/17 00:13, Matthew Pash wrote:
>     > Hi,
>     >
>     > We've got some database servers running MariaDB 10.1.22, and are having
>     > issues with logrotate.  Specifically, after it runs, it leaves a 0 byte
>     > file and continues writing log data to mysqld.log.1
>     >
>     > Manually running logrotate in verbose mode shows this error from
>     > mysqladmin when it tries to run -flush_logs:
>     >
>     > /usr/bin/mysqladmin: flush failed; error: 'Unknown error'
>     > error: error running non-shared postrotate script for
>     > /var/log/mysqld.log of '/var/log/mysqld.log '
>     > set default create context
>
>     What does the logrotate script look like? It really should be a "shared"
>     (in a logrotate way) script.
>
>
>
>     > Has anyone seen this before?  It doesn't look like a permissions error -
>     > the logs are created fine if you run systemctl restart mariadb.
>
>     Is the log actually writing to /var/log/mysqld.log using systemd? It
>     normally writes to the journal because with systemd redirects stderr
>     there
>
>
> From lsof, it looks like /var/log/mysqld.log is being written to by the
> mysql process itself:
> $ sudo lsof | grep mysqld.log
> mysqld    38803         mysql    1w      REG                8,3
> 31781  537216904 /var/log/mysqld.log.1
> mysqld    38803         mysql    2w      REG                8,3
> 31781  537216904 /var/log/mysqld.log.1
> ...
>
>
>
>
>     > Thanks,
>     > ~Matt
>     >
>     > --
>     > *Matthew*
>     > Senior Systems Administrator, IT Services
>     > University of Bristol
>     >
>     >
>     > _______________________________________________
>     > Mailing list: https://launchpad.net/~maria-discuss

>     <https://launchpad.net/%7Emaria-discuss>
>     > Post to     : maria-discuss@lists.launchpad.net
>     <mailto:maria-discuss@lists.launchpad.net>
>     > Unsubscribe : https://launchpad.net/~maria-discuss
>     <https://launchpad.net/%7Emaria-discuss>
>     > More help   : https://help.launchpad.net/ListHelp
>     <https://help.launchpad.net/ListHelp>
>     >
>
>
>
>
> --
> *Matthew Pash*

> Senior Systems Administrator, IT Services
> University of Bristol