Virtualmin backups fail due to "event scheduler is disabled (1577)" after manual MariaDB upgrade on Rocky 9

OS type and version Rocky 8 / Rocky 9
Webmin version 2104 / 2101

As the event scheduler is disabled, I can not backup all my MariaDB’s.
Also transfer a virtualmin to another server (from the rocky 8 server to the rocky 9 server) is not possible due to this error in the backup fase of the transfer.

I surfed the net and tried to enable the event scheduler by putting commands in terminal / the command shell and in php.ini
None of this methods was succesfull.

Please advice

why do you need the mysql event scheduler enabled to perform a backup ? I have never had the event scheduler enabled and never had a problem. It sounds like you have a mysql problem , however you have not stated which mysql you are using so finding out the problem is more difficult without this information.
Go To webmin->servers->mysql database server->MySQL System Variables and search on the word event you will see something like this

use button 1 to search
don’t use button 2 to edit the config, it takes you to the wrong place, instead go to webmin->servers->mysql database server->Edit Config Files and add the event scheduler line in the correct config file, my guess any file that has a [mysqld] heading, after editing restart mysql server . But this will not fix a backup problem you need to look at the logs to find out why it’s failing.

When performing a backup on MariaDB 10.11.5, the following error occurs

On another server running MariaDB 10.3.39 backing up the same DB works just fine.

On both servers the event scheduler is not enabled

I think this is an OS issue not MariaDB and not Virtualmin.
Why is it ( the mysql event scheduler) needed?

All Ubuntu 20 / 22 and MariaDB v10.6.12 = backup with no errors and no mysql event scheduler!

One of the servers having this issue is running on rocky 8, the other problematic one is on rocky 9.
The server that is backing up OK, is on rocky 8 aswel.
The only difference between the two Rocky 8 servers is the version of Mariadb
(10.3=OK, 10.11= not OK)
I already transferred the server that was ok to the rocky 9 environment so I can use the ok server for testing. I will upgrade the mariadb to 10.11.
If backup is giving a problem after upgrade, we can be sure it is a mariadb mather

I have absolutely no idea why event scheduler should be active.

I update the good server to Mariadb 10.11 and the same error is there.
Tried upgrade further to 11.1 and the same thing is happening (+ another error about “/usr/bin/mysqldump: Deprecated program name”)

I start thinking the backup button in the webmin interface is calling an old function that is not working with the newer MariaDB versions. doing backups from the Command line is working good in all versions.
use ‘/usr/bin/mariadb-dump’ instead of /usr/bin/mysqldump

I’ve done some testing:

Clean install Rocky 9
Install virtual min pro with installation file from “software-licenses”
Installation of MariaDB 10.5 is part of this installation
Backup is working as it should

Stop MariaDB server
Remove Mariadb
Install MariaDB 10.11 via repo.
Start MariaDB
Backup is not working
Error message: mysqldump: Couldn’t execute ‘show events’: Cannot proceed, because event scheduler is disabled (1577)

Isn’t that a big No No?

I thought that was one of the reasons for doing a clean install. By uninstalling a core dependency (in this case MariaDB) especially a downgrade. upsets the internals of Virtualmin. The basic clean install has known the newer version so will be assuming that version during backup etc.

Although 10.11 is theoretically better than 10.5 perhaps it is not the current version or it would have been installed initially or as part of initial updates.

stick with the distro’s default installing other versions can cause problems, as you found out.
For example with Ubuntu I would not use the virtualmin script installer for phpmyadmin (ubuntu server) simply for the reason you could install something that is not compatible with the underlying distro, stick to the distro defaults

If you want to use Moodle 4.1 to 4.3, Mariadb 10.6.7 is the minimal requirement.
The standard install with the virtualmin is 10.5. So you can’t use the Moodle 4xx without upgrading the db. Sticking to the distro default is kind of not evolving. The Mariadb 10.5 had his first release in December 2019 and is end of life in July 2025.
I like to have the last stable version of a generation on my production servers as they combine maximum safety and stability. The last stable version of Mariadb 10 is the 10.11.5
I probably stick to that for a few more years before upgrading to 11 except when it is required for using som other package that I need. It is not because you use a GUI like virtulmin that Commandline doesn’t exists anymore. I like virtualmin because it is getting you to a starting point very fast. From there it should be possible to choose and install the packages you need.

It is not a downgrade. I remove 10.5 and install 10.11 instead.
That is needed to run moodle 4.1 and up.

The current last stable version of MariaDB is 11.1.2
Theoretically, there is no need to change the virtualmin install for every new version of php and or mariadb because it is not difficult to upgrade using yum or dnf.
In this case however, there is an incompatibility between the virtualmin backup and server transfer function and the newer mariadb versions

So isn’t that the fault of the OS chosen?

But it seems that the chosen OS disagrees with that policy

You can install whatever junk you like on top of Virtualmin but don’t expect Virtualmin to have some foresight to know what that may be. I have come to expect that it respects what the given OS puts up as “approved” updated packages. It leaves any other apps very much up to us as users.

I have NodeJS and Mongoose (Mongo\DB) on all of my boxes and I do not expect Virtualmin to know about or care about them or anything else → my add-on my problem. the same would apply if I chose to add Moodle or (insane enough to add WordPress)

Mariadb is the most common db in almost all Linux distributions. Not what I call junk.
Rocky is a RHEL distribution on the end of the pipeline. Only adjustments that are stable, make it in to Rocky. Centos is in the beginning of the pipeline. That is why centos has functions that far ahead of other linux distributions. Very nice but I stick to Rocky for production servers. Also no junk to me.
Moodle is the LMS with the most users worldwide. Moodle on linux is used by the largest schools, universities and companies. No junk in my opinion.
Also, moodle 4.3 is a standard package you can install with the virtualmin pro license . In order to run it, you need a higher mariadb version than installed with virtualmin, so upgrade the db is necessary.

@Dagwin The solution for your problem is as simple as:

mysql_upgrade -u root -p
systemctl restart mariadb

This was the solution !!!
After the mysql upgrade the DB was behaving as it should.

1 Like

I was not referring to MariaDB as “junk” I was referring to all the extra stuff we all choose to add after Virtualmin (and applies to just about everything in a global sense and probably would apply to all the “other” stuff I choose to add.

I was not aware of that. So just because it comes with the pro licence (btw. it doesn’t with the GPL), this was the first mention of a “Pro” licence. I can see that you might be miffed that the Pro version script does not mention the fact that it (the script) does not warn you it is only for the previous version of Moodle.

The popularity of an app has no impact on my view of the app being of any use (we would all be using Microsoft if that was the case) WordPress is popular especially as a start point but we all know the problems it brings with it. Google was great initially until they wanted to take over the world - now look at the mess it (and other) make of websites and the internet.

That sounds like a good update on the next Virtualmin version as it shouldn’t break older installation of MariaDB. But again I can’t see why Virtualmin can be expected to foresee this. Virtualmin is working with old instruction on all the OS installs that are up to date. It seems to only be because this particular downstream addon has chose a later version of MariaDB.

So let me gaze into my crystal ball again, and see the mess that will be generated in the years to come. AI anyone?

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.