Thanks Ben for the very thorough bug report! What is the contents of /home/ben/.local/share/akonadi/db_data? The first crash log (mysql-sad.err) has a lot of warnings about missing files that are suspicious.
The error that is thrown in the 11.8.5 start that succeeded to start anyway is very confusing, so I filed upstream a bug report about it: https://jira.mariadb.org/browse/MDEV-38802 But this is clearly not the cause of the crash. I also browsed upstream Jira for people reporting new crashes and recent 11.8.6 commits for signs of relevant changes to get_schema_privileges_for_show but I didn't find anything that looks like this. I also checked the most recent entries at https://tracker.debian.org/media/packages/a/akonadi/changelog-425.12.1-2 in case Akonadi has any major changes, but I don't see anything special. If there isn't something clearly broken with Akonadi and the data directory or how MariaDB is started/restarted we should file a bug report in MariaDB at jira.mariadb.org about a potential 11.8.6 regression. > > In both cases seems MariaDB is doing crash recovery and then crashing again. > > This is just because Akonadi keeps trying to restart. I'll attach a log > showing the first crash after upgrade, without the crash recovery attempt. > > > The latter log has this line: > > 2026-02-09 0:54:21 0 [ERROR] Can't open and lock privilege tables: Table > > 'mysql.servers' doesn't exist > > > > But there is no way to tell if this is the cause or a symptom of the crash. > > I don't know why that is happening on my machine but not on Matthias's > machine, but it may be unrelated to this bug. That message also appears > when using the old version, which apparently works fine. I'll attach a > log of that too, for comparison. > > For both logs, I've set log_warnings=10 in > ~/.local/share/akonadi/mysql.cnf and disabled AppArmor enforcement. It > doesn't look like there is a meaningful difference in the log files > before the signal handler is invoked. > > I'm not sure why the included backtrace only goes as far as the signal > handler. I've added core_file to mysql.cnf and obtained a more > interesting backtrace with gdb. > > "gdb-full.bt" is the backtrace as recommended by > https://mariadb.com/docs/server/reference/product-development/mariadb-fault-finding/how-to-produce-a-full-stack-trace-for-mariadbd#getting-backtraces-with-gdb-on-linux > > Frankly, I can't comprehend that file, so I've also included a simple > backtrace for Thread 1, as "gdb.bt" > > There does seem to be some hint of a cause in the backtrace - in 11.8.5, > get_schema_privileges_for_show() didn't call acl_get_all3(). See Thread > 1, frames #9 and #10. > > > Ben
