AppArmor configuration for Akonadi's mysql is broken

[Lukáš Karas]

In akonadi-backend-mysql 19.12.3-0ubuntu2 (Focal) is AppArmor configuration file /etc/apparmor.d/mysqld_akonadi that holds "mysqld_akonadi" profile. After upgrade Akonadi to this version, it fails during startup, with mysql server error:

mysqld: [ERROR] Failed to open required defaults file: /home/karry/.local/share/akonadi/mysql.conf

in kernel log (dmesg) is apparmor message:

[16787.303724] audit: type=1400 audit(1586984985.384:353): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/home/karry/.local/share/akonadi/mysql.conf" pid=24305 comm="mysqld-akonadi" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

Profile "/usr/sbin/mysqld" is placed in file "/etc/apparmor.d/usr.sbin.mysqld" from package mysql-server-8.0_8.0.19-0ubuntu4.

It seems to me that akonadi profile should contains real path to mysqld executable (/usr/sbin/mysqld-akonadi is just symlink to mysqld)

After simple patch, Akonadi works fine:

sudo sed 's|mysqld_akonadi|/usr/sbin/mysqld|' -i /etc/apparmor.d/mysqld_akonadi
sudo systemctl reload apparmor
akonadictl start

[Lukáš Karas (lukas-karas)]

Interesting, when I build and install akonadi from upstream, it brings /etc/apparmor.d/usr.bin.akonadiserver profile that contais this line:

/usr/{,s}bin/mysqld PUx -> mysqld_akonadi,

and then mysqld seems to be running with mysqld_akonadi profile.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Andy Goossens (andygoossens)]

I had the same issue. Following the instructions in the ticket description has fixed the issue for me.

[k3mist (k3mist)]

Ticket description also worked for me. Thank you

[Marco Antonio Alvarez (surakin)]

This instructions fix the problem but apparently they have to be applied after every restart :-\

[Juan Carlos Amengual (jcamen-lsi)]

I have this same bug in Kubuntu 20.04. I have performed a fresh install of Kubuntu 20.04 over the Kubuntu 18.04 installed in my laptop. I formatted the root (/) and swap partitions, but kept the data in /home. Everything is working fine with the exception of the akonadi server which, in practice, renders unusable all of the KDE apps that depend on personal information management (knotes, kaddressbook, kmail...). And I think that this is a **huge** bug which should be solved as soon as possible.

I have followed the instructions given in the bug description and they didn't work. As root:

# sed 's|mysqld_akonadi|/usr/sbin/mysqld|' -i /etc/apparmor.d/mysqld_akonadi
# diff /root/mysqld_akonadi.ORIGINAL mysqld_akonadi
5c5
< profile mysqld_akonadi {
---
> profile /usr/sbin/mysqld {
# systemctl reload apparmor.service

As normal user:

$ akonadictl start
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
org.kde.pim.akonadiserver: Starting up the Akonadi Server...
org.kde.pim.akonadiserver: Failed to connect to database!
org.kde.pim.akonadiserver: Database error: "Can't connect to local MySQL server through socket '/run/user/1114/akonadi/mysql.socket' (2) QMYSQL: Unable to connect"
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/run/user/1114/akonadi/mysql.socket' (2)'
Check that mysqld is running and that the socket: '/run/user/1114/akonadi/mysql.socket' exists!
org.kde.pim.akonadiserver: Failed to remove runtime connection config file
org.kde.pim.akonadiserver: Shutting down AkonadiServer...
org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited normally...

There is nothing suspicious in /var/log/mysql/error.log (in fact, it is empty). The worst thing is this:

# ps aux | grep mysql
mysql 1231 0.2 1.8 2070104 297892 ? Ssl ago15 14:06 /usr/sbin/mysqld

# service mysql stop
# service mysql start
Job for mysql.service failed because the control process exited with error code.
See "systemctl status mysql.service" and "journalctl -xe" for details.
root@hermes:/etc/apparmor.d# ps aux | grep mysql
root 161552 0.0 0.0 11532 740 pts/5 S+ 20:00 0:00 grep --color=auto mysql
# systemctl status mysql.service
● mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Tue 2020-08-18 20:00:27 CEST; 51s ago
    Process: 161540 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
    Process: 161548 ExecStart=/usr/sbin/mysqld (code=exited, status=1/FAILURE)
   Main PID: 161548 (code=exited, status=1/FAILURE)

ago 18 20:00:27 hermes systemd[1]: mysql.service: Scheduled restart job, restart counter is at 5.
ago 18 20:00:27 hermes systemd[1]: Stopped MySQL Community Server.
ago 18 20:00:27 hermes systemd[1]: mysql.service: Start request repeated too quickly.
ago 18 20:00:27 hermes systemd[1]: mysql.service: Failed with result 'exit-code'.
ago 18 20:00:27 hermes systemd[1]: Failed to start MySQL Community Server.

Once the original mysqld_akonadi file is r...

[Aldo Latino (aldolat)]

@Juan Carlos Amengual (jcamen-lsi)

I wrote a note about the workaround that I am using for the moment, until this situation is resolved.
You can find this note among my Gists: https://gist.github.com/aldolat/e8066baf8a390e5d5f5ed6e0849ec78c

[Juan Carlos Amengual (jcamen-lsi)]

Thanks a lot, Aldo. It has worked.

I see that your workaround was originally prepared to solve a dependency problem that is no longer present: the package "akonadi-backend-mysql" is installed in my system. But since the bug is in the working of the akonadi-mysql server your workaround works fine since, this way, we tell akonadi to use the mySQL server for its database instead of its own server. Brilliant. Thanks again.

After doing some research and with your workaround in mind, this makes me think that the problem is that a valid "akonadi-mysql" profile is missing in the apparmor package in Kubuntu 20.04, don't you think so?

[Aldo Latino (aldolat)]

You're welcome, Juan Carlos.

I think that the dependency problem still exists: Akonadi needs mariadb-client-core-10.3, which is removed by mysql-server.

Regarding AppArmor, in the past I had to launch "sudo apparmor teardown" (or something similar) before opening Kontact. Now it doesn't make any effect. I don't know AppArmor in detail.

[Ernst Kloppenburg (ernst-kloppenburg)]

I experienced this problem, "Failed to open required defaults file: ..."
after upgrade from 18.04 to 20.04.

For me it helped to remove akonadi and all of its dependencies
    apt-get --purge autoremove akonadi-server

and then
    apt-get install kmail
etc.

[Lukáš Karas (lukas-karas)]

Fix merged to upstream: https://phabricator.kde.org/D29030#665411

It is fixed in Akonadi 20.08 that is available in (K)Ubuntu 20.10.

[Lukáš Karas (lukas-karas)]

Fix merged to upstream: https://phabricator.kde.org/D29030#665411

It is fixed in Akonadi 20.08 that is available in (K)Ubuntu 20.10.