Details
-
Bug
-
Status: In Review (View Workflow)
-
Major
-
Resolution: Unresolved
-
12.3
-
None
-
Notable changes
Description
mysql_upgrade can sometimes fail in buildbot as follows:
main.mysql_upgrade w7 [ fail ]
|
Test ended at 2026-08-05 13:17:29
|
CURRENT_TEST: main.mysql_upgrade
|
--- /home/buildbot/aarch64-debian-11/build/mysql-test/main/mysql_upgrade.result 2026-08-05 12:40:55.000000000 +0000
|
+++ /home/buildbot/aarch64-debian-11/build/mysql-test/main/mysql_upgrade.reject 2026-08-05 13:17:29.343392779 +0000
|
@@ -460,6 +460,8 @@
|
Phase 8/8: Running 'FLUSH PRIVILEGES'
|
OK
|
DROP USER mysqltest1@'%';
|
+Warnings:
|
+Note 4227 Dropped users 'mysqltest1'@'%' have active connections. Use KILL CONNECTION if they should not be used anymore.
|
Reading datadir from the MariaDB server failed. Got the following error when executing the 'mysql' command line client
|
ERROR 1045 (28000): Access denied for user 'mysqltest1'@'localhost' (using password: YES)
|
FATAL ERROR: Upgrade failed
|
It doesn't fail all the time and does so only sporadically.
It is about this fragment from mysql_upgrade.test:
#
|
# Bug #25452 mysql_upgrade access denied.
|
#
|
|
|
# Password protect a root account and run mysql_upgrade
|
|
|
CREATE USER mysqltest1@'%' IDENTIFIED by 'sakila';
|
GRANT ALL ON *.* TO mysqltest1@'%';
|
--echo Run mysql_upgrade with password protected account
|
--exec $MYSQL_UPGRADE --force --user=mysqltest1 --password=sakila 2>&1
|
|
|
DROP USER mysqltest1@'%';
|
My best guess is that here the "DROP USER" can sometimes start while mysql_upgrade's connection is not fully disbanded of.