some crashes fixed: https://mariadb.com/kb/en/mariadb-10-5-21-release-notes/
This update fixes crashes in - InnoDB-engine (e.g. join and derrived tables) - Optimizer component References: ======================== https://mariadb.com/kb/en/mariadb-10-5-21-release-notes/ Updated packages in core/updates_testing: ======================== mariadb-client-10.5.21-1.mga8 mariadb-client-debuginfo-10.5.21-1.mga8 mariadb-core-10.5.21-1.mga8 lib64mariadbd19-10.5.21-1.mga8 lib64mariadb-embedded-devel-10.5.21-1.mga8 mariadb-connect-debuginfo-10.5.21-1.mga8 mariadb-mroonga-debuginfo-10.5.21-1.mga8 mariadb-common-10.5.21-1.mga8 mariadb-debuginfo-10.5.21-1.mga8 mariadb-bench-debuginfo-10.5.21-1.mga8 mariadb-spider-debuginfo-10.5.21-1.mga8 mariadb-connect-10.5.21-1.mga8 mariadb-spider-10.5.21-1.mga8 mariadb-extra-debuginfo-10.5.21-1.mga8 mariadb-sphinx-debuginfo-10.5.21-1.mga8 mariadb-feedback-debuginfo-10.5.21-1.mga8 mariadb-10.5.21-1.mga8 lib64mariadb3-debuginfo-10.5.21-1.mga8 mariadb-obsolete-debuginfo-10.5.21-1.mga8 lib64mariadb3-10.5.21-1.mga8 mariadb-common-core-10.5.21-1.mga8 mariadb-sequence-debuginfo-10.5.21-1.mga8 mariadb-rocks-10.5.21-1.mga8 mariadb-extra-10.5.21-1.mga8 mariadb-sphinx-10.5.21-1.mga8 mariadb-obsolete-10.5.21-1.mga8 mariadb-pam-10.5.21-1.mga8 mariadb-pam-debuginfo-10.5.21-1.mga8 mariadb-sequence-10.5.21-1.mga8 mariadb-feedback-10.5.21-1.mga8 mysql-MariaDB-10.5.21-1.mga8 lib64mariadb-devel-debuginfo-10.5.21-1.mga8 mariadb-mroonga-10.5.21-1.mga8 lib64mariadb-devel-10.5.21-1.mga8 mariadb-debugsource-10.5.21-1.mga8 lib64mariadbd19-debuginfo-10.5.21-1.mga8 mariadb-core-debuginfo-10.5.21-1.mga8 mariadb-common-debuginfo-10.5.21-1.mga8 mariadb-bench-10.5.21-1.mga8 lib64mariadb-embedded-devel-debuginfo-10.5.21-1.mga8 mariadb-rocks-debuginfo-10.5.21-1.mga8 SRPM: mariadb-10.5.21-1.mga8.src.rpm
Assignee: mageia => qa-bugs
CC: (none) => mageia
Created attachment 13877 [details] CLI output of akonadi/mariadb checks Tested in KDE Plasma with Kontact/Kmail x86_64 Tests so far mysql_upgrade akonadiconsole Kontact/KMail No regression found. Best regards, Ulrich
CC: (none) => bequimao.de
Installed and tested without issues. Tested for a week. No issues or regressions found. Tested: - mysql CLI; - phpMyAdmin; - MySQL Workbench; - PHP scripts using PDO/mysql; - Qt6 apps using mysql plugin. - systemd unix and TCP/IP sockets activation. - systemd restricted execution for improved security. System: Mageia 8, x86_64, AMD CPU. $ uname -a Linux marte 6.1.33-desktop-1.mga8 #1 SMP PREEMPT_DYNAMIC Sat Jun 10 10:29:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | grep mariadb | sort lib64mariadb3-10.5.21-1.mga8 mariadb-10.5.21-1.mga8 mariadb-client-10.5.21-1.mga8 mariadb-common-10.5.21-1.mga8 mariadb-common-core-10.5.21-1.mga8 mariadb-core-10.5.21-1.mga8 mariadb-extra-10.5.21-1.mga8 $ systemctl status mysqld.socket mysqld.service ● mysqld.socket - mysqld Server Socket Loaded: loaded (/usr/local/lib/systemd/system/mysqld.socket; enabled; vendor preset: disabled) Active: inactive (dead) since Thu 2023-06-15 23:46:03 WEST; 1min 15s ago Triggers: ● mysqld.service Listen: /run/mysqld/mysqld.socket (Stream) 127.0.0.1:3306 (Stream) CPU: 314us jun 15 23:45:45 marte systemd[1]: Listening on mysqld Server Socket. jun 15 23:46:03 marte systemd[1]: mysqld.socket: Succeeded. jun 15 23:46:03 marte systemd[1]: Closed mysqld Server Socket. ● mysqld.service - MySQL database server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; disabled; vendor preset: disabled) Drop-In: /etc/systemd/system/mysqld.service.d └─override.conf Active: active (running) since Thu 2023-06-15 23:46:04 WEST; 1min 15s ago TriggeredBy: ● mysqld.socket Process: 31271 ExecStartPre=/usr/sbin/mysqld-prepare-db-dir (code=exited, status=0/SUCCESS) Main PID: 31285 (mysqld) Status: "Taking your SQL requests now..." Tasks: 21 (limit: 19046) Memory: 70.5M CPU: 327ms CGroup: /system.slice/mysqld.service └─31285 /usr/sbin/mysqld jun 15 23:46:03 marte mysqld[31285]: 2023-06-15 23:46:03 0 [Note] InnoDB: 10.5.21 started; log sequence number 56837986; transaction id 4018175 jun 15 23:46:03 marte mysqld[31285]: 2023-06-15 23:46:03 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool jun 15 23:46:04 marte mysqld[31285]: 230615 23:46:04 server_audit: MariaDB Audit Plugin version 1.4.14 STARTED. jun 15 23:46:04 marte mysqld[31285]: 230615 23:46:04 server_audit: Query cache is enabled with the TABLE events. Some table reads can be veiled.2023-06-15 23:46:04 0 [Note] Server socket created on IP: '127.0.0.1'. jun 15 23:46:04 marte mysqld[31285]: 2023-06-15 23:46:04 0 [Note] Reading of all Master_info entries succeeded jun 15 23:46:04 marte mysqld[31285]: 2023-06-15 23:46:04 0 [Note] Added new Master_info '' to hash table jun 15 23:46:04 marte mysqld[31285]: 2023-06-15 23:46:04 0 [Note] /usr/sbin/mysqld: ready for connections. jun 15 23:46:04 marte mysqld[31285]: Version: '10.5.21-MariaDB' socket: '/run/mysqld/mysqld.socket' port: 3306 Mageia MariaDB Server jun 15 23:46:04 marte systemd[1]: Started MySQL database server. jun 15 23:46:04 marte mysqld[31285]: 2023-06-15 23:46:04 0 [Note] InnoDB: Buffer pool(s) load completed at 230615 23:46:04 $ $ cat /etc/systemd/system/mysqld.service.d/override.conf # If "skip-networking" is set in the configuration then "AF_INET AF_INET6" # should be removed from RestrictAddressFamilies and PrivateNetwork=should # be set to "yes". [Service] #PrivateNetwork=yes PrivateUsers=yes PrivateTmp=yes PrivateDevices=yes DevicePolicy=closed UMask=0077 NoNewPrivileges=yes LockPersonality=yes MemoryDenyWriteExecute=yes RemoveIPC=yes RestrictRealtime=yes RestrictSUIDSGID=yes RestrictNamespaces=yes #RestrictAddressFamilies=AF_UNIX RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 SystemCallArchitectures=native SystemCallFilter=@system-service SystemCallFilter=~ @privileged @resources ProtectHome=yes ProtectHostname=yes ProtectKernelLogs=yes ProtectClock=yes ProtectControlGroups=yes ProtectKernelModules=yes ProtectKernelTunables=yes ProtectKernelLogs=yes ProtectSystem=strict AmbientCapabilities= CapabilityBoundingSet= StateDirectory=mysql RuntimeDirectory=mysqld
MGA8-64 MATE on Acer Aspire 5253 No installation issues, overwriting previous version. Made sure httpd and mysqld are running, tried to open phpMyadmin, but this results in a blank tab on firefox, no feedback. And after a few minutes, the disk activity goes to 100% (on viewing the laptop LED) and the response times grow to next to unworkable. At CLI I get error 1698 cannot connect to 'root'@'localhost'. The ' seems strange to me.
CC: (none) => herman.viaene
Sorry, the error is "Access denied".
@Herman, what does this mean?
@Herman, what processes are doing all the disk activity? Are there any error in the logs (journalctl, /var/log/httpd)? Did phpMyadmin work before? Did you run "mysql_upgrade --skip-write-binlog -uroot -p"?
It means that apparently the mysql server starts OK, but I cann't find a way to access it. Which was a no-brainer in the previous update-tests. I have done a number of those in the past years. I am now googling for a solution if this could be some config issue, but so far no success. And yes, phpMyadmin worked before OK. I've not yet been able to check processes since once this is going, the system is for all practical purposes completely blocked. And no, I did not run that command, I will try.
# mysql_upgrade --skip-write-binlog -u root -p Enter password: This installation of MariaDB is already upgraded to 10.5.16-MariaDB. There is no need to run mysql_upgrade again for 10.5.21-MariaDB. You can use --force if you still want to run mysql_upgrade
Nothing in /var/log/httpd. Journalctl nothing else but "Access denied"
It's working here after start mysqld.service and httpd.service The mysqld had previously been setup as per /usr/share/doc/mariadb/README.urpmi In firefox, http://127.0.0.1/phpmyadmin/ gets the login page. I enter the user "root" and the root user's mysql password setup as per the README.urpmi file. Note that the mysql password doesn't have to be the same as the root user's login password. It can/should be different. After that phpmyadmin is working normally for viewing the structures, etc.
CC: (none) => davidwhodgins
Regarding the urpmi.README which could be clearer. On an initial install, just run mysql_secure_installation The mysql_upgrade step is only needed when the database mysql has new tables or the tables in that database have had changes. That's usually only needed right after upgrading from one Mageia release to the next. Once it's working, updates do not normally require any action to keep mysqld.service working.
(In reply to Herman Viaene from comment #10) > Nothing in /var/log/httpd. > Journalctl nothing else but "Access denied" Double check your settings in firefox. At the end of about:preferences#privacy ensure "Don’t enable HTTPS-Only Mode" is selected and that it's using http://127.0.0.1/phpmyadmin/ not https://127.0.0.1/phpmyadmin/
(In reply to Herman Viaene from comment #8) > I've not yet been able to check processes since once this is going, the > system is for all practical purposes completely blocked. From what you described, it seems the systems runs out of memory and starts swapping. Try running a monitor program, like htop, with high priority (nice -n 10 htop), as root, on the console, and then start mysqld service to see what processes are doing and how the system behaves.
(In reply to Dave Hodgins from comment #13) > (In reply to Herman Viaene from comment #10) > > Nothing in /var/log/httpd. > > Journalctl nothing else but "Access denied" > > Double check your settings in firefox. At the end of > about:preferences#privacy > ensure "Don’t enable HTTPS-Only Mode" is selected and that it's using > http://127.0.0.1/phpmyadmin/ not https://127.0.0.1/phpmyadmin/ Setting is OK, http gives page with "Access denied".
(In reply to Herman Viaene from comment #15) > Setting is OK, http gives page with "Access denied". That seems to be a configuration issue in the HTTP server (apache?) and not a mariadb issue.
Confirm mysql is ok .... $ mysql -u root -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 111 Server version: 10.5.21-MariaDB Mageia MariaDB Server Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> SHOW DATABASES; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | oct8test | | performance_schema | | sympa | | zm | +--------------------+ 6 rows in set (0.004 sec) MariaDB [(none)]> quit; Bye Make sure the package pgadmin4-web is installed, not just pgadmin4. Also does http://localhost/ show the "It works!" page?
Don't blame everything on the issue http - phpmyadmin. As I wrote in Comment 4, the mysql command at the CLI throws the "Access denied" as well. In the mean time I had restored a backup from 2023-05-26 (only one partition involved in my test-setup) and I get the following with the old versions of kernel, firefox, mysql: # mysql Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 24 Server version: 10.5.20-MariaDB Mageia MariaDB Server Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> quit Bye but $ mysql -u root ERROR 1698 (28000): Access denied for user 'root'@'localhost' And that is not normal. I also followed the suggestion of Comment 14, running htop. And there I see that starting httpd and mysqld raises CPU and mem occupancy but not alarmingly. But as soon as I try to start phpMyadmin (getting nowhere as described above) I see the numbers of mem for the http processes increasing until getting too high and swapping kicking in. Stopping httpd returns the system to normal behavior and mem occupancy drop to sensible levels. So there seem to be 2 problems here ?????. I haven't older backups available, so I wonder whether I should better re-install the M8 alltogether from scratch.
And BTW, I did the same tests on M9, works like a charm.
@Herman, does the command "mysql -u root -p" ask for a password? Do you have a password set for mysql's root user? (may not be the same as the system root user).
No, it does not ask for a password, and yes, there is a password set.
Sorry, I was busy on the weekend. If access denied is issued via mysqld, you shoud have at least an entry in /var/log/mysqld/mysql.err.log or wherever "log-error" points to.
(In reply to Herman Viaene from comment #21) > No, it does not ask for a password, and yes, there is a password set. Depending on the configuration it is possible to login as root without authentication if connecting through the unix socket. I don't know if that your case. Check the logs, maybe there are clues in there. Depending on the configuration, logs can be found in: - systemd journal (journalctl -b0 -u mysqld.service); - /var/log/mysqld/*.log - /var/lib/mysql/*.log - some other file set in the config files /etc/my.cnf and /etc/my.cnf.d/*
Forget about all noise. Completely reinstalled M8 from scratch. Updated kernel and tested with mysql 10.5.20, all OK. Did full update and then tested 10.5.21, Connection at CLI and database operations using phpMyadmin work OK. I will now make a backup for this system and then check the pending mediawiki update. As this uses alos mysql and had unexpected errors, I guess it sufferred from the same corruption. As others hac no problems with this update, giving the OK and tx for your assistance.
Whiteboard: (none) => MGA8-64-OK
Validating the update. Advisory committed to svn.
Keywords: (none) => advisory, validated_updateCC: (none) => sysadmin-bugs
@Herman: no worries. I'm glad you test, and I know those days where everything goes wrong :)
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2023-0052.html
Status: NEW => RESOLVEDResolution: (none) => FIXED