This might be a bug in the 'stock' configuration when using mariadb as opposed to mysql that hasn't been stamped out yet, as I vaguely remember running into something similar myself when moving over to mariadb from mysql.

You will want to look in /etc/logrotate.d/mysql-server to see what is running at postrotate. You will likely have something like this:

test -x /usr/bin/mysqladmin || exit 0
if [ -f `my_print_defaults --mysqld | grep -oP "pid-file=\K[^$]+"` ]; then
    # If this fails, check debian.conf!
    mysqladmin --defaults-file=/etc/mysql/debian.cnf flush-logs
fi

Ubuntu is probably looking there, so try taking a look in /etc/mysql/debian.cnf and seeing what is set.


AvatarKava gets us pointed in the right direction and his answer will work for most people. If you're still scratching your head after adding a user and password to the /etc/mysql/debian.cnf file (even though it says not to touch this file haha!) then:

make sure you have quotes around your password

especially if there are special characters in your password.

Another hack is to remove the --defaults-file=/etc/mysql/debian.cnf option from the mysqladmin command in /etc/logrotate.d/mysql-server. If you remove this option, the root user (the user that runs logrotate) will still need a valid user and password to connect to mysql so make sure you have a proper .my.cnf file in /root. In either case, the changes to debian.cnf or mysql-server could be overwritten during the next MariaDB upgrade but as AvatarKava points out, you will probably get prompted before the upgrade overwrites these files. Worst case, you'll start getting logrotate errors again after the upgrade and will need to make the same changes again.