Issue Ubuntu 18 LTS - Logrotate error

[DerDanilo]

Cron <root@<host>> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )


Clean Ubuntu 18 LTS cloud image. Plesk installer used 4 days after official 18 LTS support announcement.
Server throws this logratate error on a daily basis.

Before I start fiddling myself I'd like to ask if this can be rather fixed through a Plesk update.

Thanks

/etc/cron.daily/logrotate:

mysqladmin: connect to server at 'localhost' failed

error: 'Access denied for user 'root'@'localhost' (using password: NO)'

error: error running shared postrotate script for '/var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/mariadb-slow.log /var/log/mysql/error.log '

run-parts: /etc/cron.daily/logrotate exited with return code 1

 

[IgorG]

It looks like a bug. Please submit it here with all necessary details - Reports
Thanks.

 

[DerDanilo]

Here you go. Ubuntu 18 LTS - Logrotate error

Sad that we have to spend extra time to report issues if we posted them already. Time is valuable.

 

[trialotto]

@DerDanilo,

I am pretty sure that your issue is related to the /etc/mysql/debian.cnf file or the contents thereof.

Can you do and check the following?

1 - open the relevant logrotate file, like: vi /etc/logrotate.d/mysql-server

2 - check the contents of that file, you should have something like:

postrotate
test -x /usr/bin/mysqladmin || exit 0
# If this fails, check debian.conf!
MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
# Really no mysqld or rather a missing debian-sys-maint user?
# If this occurs and is not a error please report a bug.
#if ps cax | grep -q mysqld; then
if killall -q -s0 -umysql mysqld; then
exit 1
fi
else
$MYADMIN flush-logs
fi

meaning that your exit status (1) is likely to be associated with a misconfiguration of OR some missing data in the debian.cnf file.

3 - check the presence of your /etc/mysql/debian.cnf file and the contents thereof: there should some content with a password in the before mentioned file.

4 - IF the /etc/mysql/debian.cnf seems to be correct, just check for the presence of a debian-sys-maint user, by running the commands:

- command: plesk db
- mysql command: SELECT User,Host,authentication_string FROM mysql.user;

and you should find a debian-sys-maint user.


If you can verify that everything is correct, then it is very likely that some actual bug is present, being a Plesk or Ubuntu related bug.

It is very very likely that it is a Ubuntu related bug, so I am not sure whether this get fixed soon.


Anyway, also note that you can do one quick test by running the command

mysql -u debian-sys-maint -p"$(cat /etc/mysql/debian.cnf | grep password | head -n 1 | awk -F= '{ gsub(/[ \t]+/, "", $2); print $2 }')"

but it is recommended to do the "manual" steps 1 to 4, since the above command only indicates that you have access to the database (read: when the mysql prompt is on your screen, then an debian-sys-maint account is working properly), it is NOT indicating any errors in your debian.cnf or logrotate related files (!).


Hope the above helps a bit......and keep us posted!

Kind regards.........

 

[DerDanilo]

Thanks for the suggestion. Will try that it I find time.

It's rather something I expect Plesk to fix during installation. Otherwise manual interaction is required and that does not work is it is suppose to deploy manually.

 

[trialotto]

@DerDanilo,

I personally did not look into the combination of Ubuntu 18.04 LTS + Plesk, but I am pretty sure that it is related to Ubuntu OS related packages.

In my humble opinion, the Ubuntu 18.04 LTS release was somewhat swift and there a lot of indications that a considerable number of Ubuntu package updates will follow.

In short, it is essentially not Plesk Team but rather Canonical that has to take action.

Kind regards.....

 

[DerDanilo]

@DerDanilo,
3 - check the presence of your /etc/mysql/debian.cnf file and the contents thereof: there should some content with a password in the before mentioned file.

The file `/etc/mysql/debian.cnf` does not contain any password. The system runs mariadb (?) installed via Plesk installer.
Login without password only works if the mysql server was restarted recently.

So how to fix that?

 

[trialotto]

@DerDanilo

I am not using MariaDB at all, as far as I know MariaDB installations generate a dummy debian.cnf with root user and blank password.

Moreover, I know that there is some history with this MariaDB related bug in versions 10.x (or even earlier, I am not sure) and patches are available..........

.................. but the patch from 2016 is the root cause of (some or another) bug in MariaDB versions 10.0, 10.1 and 10.2.

I am pretty sure that the correct patch is not introduced in the Ubuntu 18.04 LTS packages: no solution exists yet.

Again, I am not a MariaDB expert, but it seems to be the case that your issue will not get resolved soon.

I believe the patch is something like

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

at the end of the /etc/logrotate.d/mysql-server file (read: before the endscript tag).

It might be worth trying to change the before mentioned lines into

if systemctl -q is-active mariadb; then
# If this fails, check debian.conf!
mysqladmin --defaults-file=/etc/mysql/debian.cnf flush-logs
fi

and you should first run the command systemctl is-active mariadb (without the -q flag!) in order to see whether MariaDB is really active.

Otherwise, you could do a quick test of the existence of the pid file (of MariaDB) in order to execute the mysqladmin --defaults-file=/etc/mysql/debian.cnf flush-logs in the before mentioned "if logic" structure.

Hope the above helps a bit!

Kind regards........

 

[DerDanilo]

Would it help to update to the latest version of MariaDB?

I mean this is the package that the Plesk installer uses. So I don't understand why this problem was not detected earlier. It's not like that the DB is something unimportant for Plesk as it's needs it working itself.

 

[trialotto]

Would it help to update to the latest version of MariaDB?

No, probably not (as I tried to mention: there is this huge probability that all MariaDB versions 10.1, 10.2 and 10.3 are equally affected).

Plesk installer simply uses the stable release of MariaDB as shipped with the stable release of Ubuntu 18.04 LTS.

So, it has nothing to do with Plesk itself and/or detection of bugs: even if Plesk Team made a patch, every reinstall (via apt-get or aptitude) and/or reconfigure (via dpkg) command would return the original issue if the default MariaDB packages, as shipped with Ubuntu 18.04 LTS, are not patched.

In my humble opinion, the only solution seems to be applying a "dirty work-around" as long as MariaDB packages within Ubuntu 18.04 LTS are not patched.

Regards..........

 

[DerDanilo]

This is definetly a Plesk issue. I reset the password and could make the logrote`script work fine. Once logged into Plesk it changed the password to "something" and it didn't work anymore.

@plesk team
So when can we expect a solution?

 

[trialotto]

This is definetly a Plesk issue.

I am pretty sure that this is not correct, given that

I reset the password and could make the logrote`script work fine.

you apparently manually changed the /etc/mysql/debian.cnf file (otherwise, the logrotation script would not work), AND also given that

Once logged into Plesk it changed the password to "something" and it didn't work anymore.

Plesk does not affect the /etc/mysql/debian.cnf file at all, certainly not by a simple action like a login.

In my humble opinion, you are describing symptoms of something that happens in the background with MariaDB server.

Nevertheless, it is always great if Plesk Team has a look into this issue: a quick work-around could be made (temporarily) available via a Plesk patch.

Kind regards......

 

[trialotto]

@DerDanilo

By the way, I have one question: do you notice or see a lot of errors and warning notifications in /var/log/mysql/error.log? (or the MariaDB equivalent error.log).

If yes, can you please provide me with some information about the errors and warnings?

Kind regards........

 

[DerDanilo]

@DerDanilo

By the way, I have one question: do you notice or see a lot of errors and warning notifications in /var/log/mysql/error.log? (or the MariaDB equivalent error.log).
....

I will have to check this at some point this week.
Thanks for all your input and sorry for being so brief, very busy weeks.

 

[DerDanilo]

Messages about failed logrotate task are received: 'Access denied for user 'root'@'localhost' (using password: NO)

@plesk team: The syntax in the manual seems wrong. It only worked like this for me:

mysql> SELECT PASSWORD('PASSWORD');

mysql> GRANT RELOAD, SHUTDOWN, PROCESS, SHOW DATABASES, SUPER, LOCK TABLES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY PASSWORD '*PASSWORD HASH'; FLUSH PRIVILEGES;

https://support.plesk.com/hc/en-us/...ed-for-user-root-localhost-using-password-NO-