In the previous article I wrote about an internal server error showing up in Znuny, after the dedicated vServer was upgraded from Debian 11 (via 12) to 13.
One day later, the daily database backup (mysqldump) script ran into warnings. But to fix this, yet another problem showed up (unknown variable 'max_allowed_packet=256M').
But step by step...
As mentioned, the backup script is executed daily by cron and ran into warnings. The Shell script uses mysqldump in the background to create a dump of all local databases.
A manual execution reproduces the warnings:
root@znuny:~# /root/scripts/backup-mysql.sh
mysqldump: Couldn't execute 'show events': Cannot proceed, because event scheduler is disabled (1577)
mysqldump: Couldn't execute 'show events': Cannot proceed, because event scheduler is disabled (1577)
I've seen these kinds of errors a lot in the past years. Now that the OS (Debian Linux) was upgraded, the installed packages were also upgraded. That also means a package upgrade from MariaDB 10.5 (on Debian 11) to MariaDB 11.8 (on Debian 13).
For some unknown reasons, the automated mysql_upgrade command doesn't seem to be executed anymore after such major version upgrades. As the internal table structures might significantly change inside the system databases, a mysql_upgrade makes sure to alter these tables for the new version.
To make sure the MariaDB upgrade has run, better execute the command once after the distribution upgrade.
And now we're at the heart of this blog post. Because the mysql_upgrade command ran into the following error:
root@znuny:~# mysql_upgrade
mysql_upgrade: unknown variable 'max_allowed_packet=256M'
Some configuration seems to interfere with the mysql_upgrade command. Let's try to find it inside /etc/mysql/:
root@znuny:~# grep max_allowed_packet /etc/mysql/* -rni
/etc/mysql/conf.d/mysqldump.cnf:4:max_allowed_packet = 16M
/etc/mysql/mariadb.conf.d/50-server.cnf.dpkg-old:37:#max_allowed_packet = 1G
/etc/mysql/mariadb.conf.d/50-znuny_config.cnf:2:max_allowed_packet=256M
/etc/mysql/mariadb.conf.d/50-znuny_config.cnf:7:max_allowed_packet=256M
/etc/mysql/mariadb.conf.d/50-server.cnf:34:#max_allowed_packet = 1G
Interesting. The 50-znuny_config.cnf seems to be the issue as this is where the parameter is defined. Let's take a closer look at that cnf file:
root@znuny:~# cat /etc/mysql/mariadb.conf.d/50-znuny_config.cnf
[client]
max_allowed_packet=256M
[mysqld]
innodb_file_per_table
innodb_log_file_size = 256M
max_allowed_packet=256M
This is a config file which hasn't been touched in years, since the initial migration from OTRS CE to Znuny. Now it seems that with the MariaDB upgrade, this no longer seems to work.
A quick classic non-ai search indeed reveals a documentation bug (issue #3). The fix removes the definition of the [client] section of the 50-znuny_config.cnf file:
The previous entry would work with the mysqldump command but does interfere with other mysql/mariadb client programs, such as mysql_upgrade.
After applying this change, the config file now looks like this:
root@znuny:~# vi /etc/mysql/mariadb.conf.d/50-znuny_config.cnf
root@znuny:~# cat /etc/mysql/mariadb.conf.d/50-znuny_config.cnf
[mysql]
max_allowed_packet=256M
[mysqldump]
max_allowed_packet=256M
[mysqld]
innodb_file_per_table
innodb_log_file_size = 256M
max_allowed_packet=256M
Now with the config file adjusted, mysql_upgrade now runs again:
root@znuny:~# mysql_upgrade
Phase 1/8: Checking and upgrading mysql database
Processing databases
mysql
mysql.column_stats OK
mysql.columns_priv OK
mysql.db OK
mysql.event OK
mysql.func OK
mysql.global_priv OK
mysql.gtid_slave_pos OK
mysql.help_category OK
mysql.help_keyword OK
[...]
znuny.virtual_fs OK
znuny.virtual_fs_db OK
znuny.virtual_fs_preferences OK
znuny.web_upload_cache OK
znuny.xml_storage OK
Phase 7/8: uninstalling plugins
Phase 8/8: Running 'FLUSH PRIVILEGES'
OK
With the now upgraded MariaDB schema, the mysqldump backup script completes successfully again, too:
root@znuny:~# /root/scripts/backup-mysql.sh
root@znuny:~# echo $?
0
AWS Android Ansible Apache Apple Atlassian BSD Backup Bash Bluecoat CMS Chef Cloud Coding Consul Containers CouchDB DB DNS Databases Docker ELK Elasticsearch Filebeat FreeBSD Galera Git GlusterFS Grafana Graphics HAProxy HTML Hacks Hardware Icinga Influx Internet Java KVM Kibana Kodi Kubernetes LVM LXC Linux Logstash Mac Macintosh Mail MariaDB Minio MongoDB Monitoring Multimedia MySQL NFS Nagios Network Nginx OSSEC OTRS Observability Office OpenSearch PHP Perl Personal PostgreSQL PowerDNS Proxmox Proxy Python Rancher Rant Redis Roundcube SSL Samba Seafile Security Shell SmartOS Solaris Surveillance Systemd TLS Tomcat Ubuntu Unix VMware Varnish Virtualization Windows Wireless Wordpress Wyse ZFS Znuny Zoneminder