I cannot use my kmail email client due to akonadi server not being started. To
debug it I have tried the following:
# akonadictl start
org.kde.pim.akonadictl: Starting Akonadi Server...
org.kde.pim.akonadictl:    done.
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
org.kde.pim.akonadiserver: Starting up the Akonadi Server...
org.kde.pim.akonadiserver: database server stopped unexpectedly
org.kde.pim.akonadiserver: Database process exited unexpectedly during initial
connection!
org.kde.pim.akonadiserver: executable: "/usr/sbin/mysqld"
org.kde.pim.akonadiserver: arguments: ("--defaults-
file=/home/cgarcia/.local/share/akonadi/mysql.conf", "--
datadir=/home/cgarcia/.local/share/akonadi/db_data/", "--
socket=/run/user/4876/akonadi/mysql.socket", "--pid-
file=/run/user/4876/akonadi/mysql.pid")
org.kde.pim.akonadiserver: stdout: ""
org.kde.pim.akonadiserver: stderr: ""
org.kde.pim.akonadiserver: exit code: 1
org.kde.pim.akonadiserver: process error: "Unknown error"
org.kde.pim.akonadiserver: Shutting down AkonadiServer...
org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited
normally...

So apparently mysql cannot be started. I have tried to manually start mysql but
I get the following message:
# /usr/sbin/mysqld --verbose --defaults-
file=/home/cgarcia/.local/share/akonadi/mysql.conf
--datadir=/home/cgarcia/.local/share/akonadi/db_data/
--socket=/run/user/4876/akonadi/mysql.socket --pid-
file=/run/user/4876/akonadi/mysql.pid
2023-03-02  9:21:47 0 [Note] Starting MariaDB 10.11.2-MariaDB-1 source revision
as process 13921
2023-03-02  9:21:48 0 [Note] InnoDB: Compressed tables use zlib 1.2.13
2023-03-02  9:21:48 0 [Note] InnoDB: Number of transaction pools: 1
2023-03-02  9:21:48 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2023-03-02  9:21:48 0 [Note] InnoDB: Using liburing
2023-03-02  9:21:48 0 [Note] InnoDB: Initializing buffer pool, total size =
128.000MiB, chunk size = 2.000MiB
2023-03-02  9:21:48 0 [Note] InnoDB: Completed initialization of buffer pool
2023-03-02  9:21:48 0 [Note] InnoDB: File system buffers for log disabled
(block size=512 bytes)
2023-03-02  9:21:48 0 [ERROR] InnoDB: Upgrade after a crash is not supported.
The redo log was created with MariaDB 10.6.11. You must start up and shut down
MariaDB 10.7 or earlier.
2023-03-02  9:21:48 0 [ERROR] InnoDB: Plugin initialization aborted with error
Generic error
2023-03-02  9:21:48 0 [Note] InnoDB: Starting shutdown...
2023-03-02  9:21:48 0 [ERROR] Plugin 'InnoDB' init function returned error.
2023-03-02  9:21:48 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE
failed.
2023-03-02  9:21:48 0 [Note] Plugin 'FEEDBACK' is disabled.
2023-03-02  9:21:48 0 [ERROR] Could not open mysql.plugin table: "Table
'mysql.plugin' doesn't exist". Some plugins may be not loaded
2023-03-02  9:21:48 0 [ERROR] /usr/sbin/mysqld: unknown variable 'defaults-
file=/home/cgarcia/.local/share/akonadi/mysql.conf'
2023-03-02  9:21:48 0 [ERROR] Aborting

That renders all KDE PIM applications unusable in Debian Bookworm.

Hi,

the issue is connected to MariaDB when upgrading after the shutdown was
not clean, see https://bugs.debian.org/cgi-bin/bugreport.cgi?
bug=1032047#40

We are trying to find a solution for this.

Le vendredi, 10 mars 2023, 21.04:56 h CEST Patrick Franz a écrit :

Enrique; the mentionned bug is now fixed; do you still experience your issue?

Best,
    OdyX

Control: tags -1 +moreinfo
Control: severity -1 serious

To me it looks like 1032047 has been fixed with a solution that makes this more
likely to happen rather than list.

If I understand the fix correctly in that bug, it is ignoring all runnig
mariadb's that is not from specific users and just upgrading anyways.

That is, to my understanding, the easiest way to hit this is exactly to
upgrade mariadb while it is not cleanly shutdown.

/Sune

Control: retitle -1 akonadi server not robust against mysql upgrades


As far as I understand the problem (as expressed in the retitle too), I
agree.

Do you have an idea what the stance of upstream is with respect to this
problem? E.g. do they say "don't upgrade mysql/mariadb while logged in"?
Or e.g. "stopping and later starting the mysql server should be ok". If
it's the latter case, I understand (including info from bug #1032047)
that the problems are:
* upgrades of mysql/mariadb can't be done in place; a clean shutdown of
every running mysql/mariadb server is required
* there are user facing buttons that invite the user to start the
akonadi backend server when it is not running; if the user session
server would be killed for the upgrade, the user might (try to) start it
before the upgrade is ready
* mysql/mariadb lack the facilities to gracefully stop and particularly
restart user session based servers

So, *if* upgrading mysql/mariadb would stop and start the user session
server correctly, would there be a problem for the user if they didn't
hit that button (apart from a temporary lack of service of course)? If
the answer is no, are there more things to solve than:
* ensuring the user can't restart the server while it's being upgraded
* ensuring that mysql and mariadb stop and restart user sessions based
servers (in a policy compliant way)

Paul

Hi,

We're running out of time for trixie.


The MariaDB maintainer didn't work on supporting the use case [1], is
there any progress on the akonadi side? If the package isn't protecting
against this failure mode, should it be mentioned in the Release Notes?

Apart from this bug report, have more reports been made? Isn't the
problem real?

Paul

[1]
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/197#note_618496

H!,

I just found this issue
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032240) when
browsing the list of release critical issues for Trixie (although it
is from 2023 and was open also when Bookworm was released, so not
really a Trixie issue).

A variant of it was
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032047 where the
MariaDB service shut down the Akonadi started MariaDB server. It was
discussed in Feb-March 2023 in that bug and fixed at the end of March
2023 by making sure the system-wide MariaDB service file does not
meddle with the Akonadi started services.

As Akonadi automatically starts the service, it should probably also
have automation to stop it on behalf of the user?

Maybe provide something the MariaDB preinstall should call? There is
no option to "stop the upgrade" in Debian. Once a user runs `apt
upgrade` it needs to complete, there is no way of stopping in the
middle or rolling back automatically. If a single maintainer script
emits `exit 1` it will only cause dpkg to fail and get caught in a
state where users are unable to install or remove anything. So,
repeating, the upgrades need to complete and there is no option to
abort them.

In Feb 2023 I emphasized the view that the MariaDB maintainer scripts
should only do things automatically for stuff that it managed in the
first place. Stopping every mysqld/mariadbd service on the system
purely by process name would seem overreaching.

Akonadi maintainers - please suggest how you want to solve this.

My suggestion is for mariaDB to not be so rigid in only being able to recover
exact versions.

I could see the same thing actually happen "unclean server crash, server
administrator reboots into some emergency shell, while at it does a system
upgrade that brings in a newer mariaDB".

I'm not sure how a user process should be able to actually deal with this.

Not running an upgrade while being in a graphical user session would probably
prevent 95% of the akonadi issues.
But it still misses the one case I previously described (that occurred to me)
 - My workstation locked up for unknown reason
 - I power cycled the work station
 - Before logging in, I switched to a terminal to do some system maintenance
 - A newer mariaDB would not fix the previous unclean stop of an older version

I'm not sure how this can be dealt with in any other ways than in mariaDB
itself.

I'm unsure though if upstream's work towards making sqlite the new default
backend and various migration helpers is in the version we are releasing with
in trixie or not.

/Sune

In Debian packaging we can't do anything about upstream capability to
recover from crashes. Please suggest what exact Akonadi service
starts/stops the database and how we can ask Akonadi to shutdown before
server upgrade. At least it would cover the common case if regular upgrades.

What you are asking is "How to ensure all logged in users email & contacts &
calendar applications are stopped before upgrading a package"

I don't think I can come up with a policy compliant way of doing that.

but `akonadictl stop` for each user after connecting to their dbus session
should do it from a technical point of view.
Maybe first diverting some files to prevent the user from starting them up
again, and then diverting back once upgraded.


But all of this is a bit euww.



/Sune

If you ship in Akonadi a facility that does the above and has some
sorts of "API" to call, I can modify the MariaDB maintainer scripts to
call it.

Regardless if you do a technical fix for this or not, you could submit
an addition to the release notes similar to what I did in
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/197
and explain to Akonadi/KDE users, that before doing the Bookworm ->
Trixie upgrade they should maybe log out all users and as a single
root user session run the `apt upgrade`?

Hej Otto,,

Am Montag, 16. Juni 2025, 19:55:23 CEST schrieb Otto Kekäläinen:

Are you looking for an API like this ?
https://invent.kde.org/pim/akonadi/-/blob/v24.12.3/src/akonadictl/
main.cpp?ref_type=tags#L211

Thanks for the source code pointer, but there is no "API" documentation
there, so you should give the exact "API call" you want the script to run.
I assume it is something more complex than `(sudo) akonadi stop`.

Hej Otto,

Am Mittwoch, 18. Juni 2025, 08:16:33 CEST schrieb Otto Kekäläinen:

akonadictl is briefly mentioned in
https://api.kde.org/kdepim/akonadi/html/server.html

The best description of the tool I could dig up can be found at
https://userbase.kde.org/Akonadi

I don't know if there's a more official documentation.

Well it is that easy ;)

# connect to correct dbus session of the user
akonadictl stop # as user
# perform the upgrade
akonadictl start # as user
#done

to check if the mysql backend for Akonadi is used:
check if that stanza is inside $XDG_CONFIG_HOME/akonadi/akonadiserverrc

[%General]
Driver=QMYSQL

The tricky part is to prevent akonadi to be started again, as it is started,
if any service wants to get data.

I think we should "just" inform while upgrading, that some Akonadi sessions
are running and that users should stop those sessions than wait for the user
to hit "OK" and than go on with the mariadb upgrade.

On Akonadi side we can add the information, that the mariadb server needs to
be stopped, when doing a mariadb server upgrade.

 This would at least improve the current situations. Maybe someone finds a
better integration.

Btw. postgresql has the same issue, that an Akonadi session needs to be
upgrades. But postgresql all us to install version based packages as they can
be co-installed on one system. That makes it possible to perform an upgrade
later. For Akonadi to do a postgresql upgrade it needs the old and the new
version packages to be installed. Still this is a pain, as you need to the
information flow between the administrator and the user.
Yes co-installable versions for mariaDB would be a solution, but this is a
wishlist for upstream and not possible for Debian to do.

Regards,

hefee