Bug#886186: akonadi-server: akonadi server fails to start mysqld due to apparmor intervention

2018-01-02 Thread Sandro Knauß
Hey,

I can't reproduce this issue for unstable. Me having 17.08.3-1 running and 
also apparmor 2.11.1-4 (running) and everything works for me.
Maybe the path for #869865 fixes your issue too?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869865

hefee

> I am following debian testing and in the course of the last months have
> twice run into the following issue:
> 
> after aptitude update/full-upgrade, akonadi-server will not start.
> Running akonadictl start from the command line I spotted the failing command
> as being the  invocation of mysqld.
> 
> I cannot provide the text of the failing command here because I upgraded
> akonadi-server and apparmor to unstable to see if the problem goes away (no
> it
> doesn't) and now akonadictl keeps crashing on me
> (and if I would downgrade the data base format does not match any longer).
> apparmor and  libapparmor are at 2.11.1-4.
> 
> However, the state of my analysis is
> 
> 1. When starting kontact, akonadi fails to invoke mysqld because the
> daemon cannot open its configuration file in my home directory
> (strace). The file exists and is world-readable. The mysqld command line
> looks unsuspicious and specifies a socket (which exists), the configuration
> file and something else which I do not remember.
> 
> 2. The problem disappears after disabling apparmor (which I did not
> explicitly install, thus the bug classification as important). A
> reboot is necessary, though - probably systemctl stop apparmor is not
> sufficient to 'really' stop it.
> 
> 3. There is a configuration file for myslqd and akonadis invocation of
> mysqld in /etc/apparmor.d
> 
>usr.sbin.mysqld
>usr.sbin.myslqd-akonadi
> 
> which I did not touch, but whose correctness I cannot judge either.
> The relevant line seems to come from usr.sbin.mysqld-akonadi
> 
>@{HOME}/.local/share/akonadi/** rwk,
> 
> which feels correct, as this describes the path to my configuration file:
> 
> root@nbof16:/home/sts# ls -l .local/share/akonadi/mysql.conf
> -rw-r--r-- 1 sts sts 3531 Jan  2 21:19 .local/share/akonadi/mysql.conf
> 
> OK - this is as far as I feel able to go. Maybe some akonadi or
> apparmor specialist can take over from here?


signature.asc
Description: This is a digitally signed message part.


Bug#886186: akonadi-server: akonadi server fails to start mysqld due to apparmor intervention

2018-01-02 Thread Stefan Schwarzer
Package: akonadi-server
Version: 4:17.08.3-1
Severity: important

Dear Maintainer,

I am following debian testing and in the course of the last months have
twice run into the following issue: 

after aptitude update/full-upgrade, akonadi-server will not start. 
Running akonadictl start from the command line I spotted the failing command
as being the  invocation of mysqld. 

I cannot provide the text of the failing command here because I upgraded 
akonadi-server
and apparmor to unstable to see if the problem goes away (no it
doesn't) and now akonadictl keeps crashing on me
(and if I would downgrade the data base format does not match any longer).
apparmor and  libapparmor are at 2.11.1-4.

However, the state of my analysis is

1. When starting kontact, akonadi fails to invoke mysqld because the
daemon cannot open its configuration file in my home directory
(strace). The file exists and is world-readable. The mysqld command line looks
unsuspicious and specifies a socket (which exists), the configuration file
and something else which I do not remember.

2. The problem disappears after disabling apparmor (which I did not
explicitly install, thus the bug classification as important). A
reboot is necessary, though - probably systemctl stop apparmor is not
sufficient to 'really' stop it.

3. There is a configuration file for myslqd and akonadis invocation of
mysqld in /etc/apparmor.d 

 usr.sbin.mysqld
 usr.sbin.myslqd-akonadi

which I did not touch, but whose correctness I cannot judge either.
The relevant line seems to come from usr.sbin.mysqld-akonadi

 @{HOME}/.local/share/akonadi/** rwk,

which feels correct, as this describes the path to my configuration file:

root@nbof16:/home/sts# ls -l .local/share/akonadi/mysql.conf 
-rw-r--r-- 1 sts sts 3531 Jan  2 21:19 .local/share/akonadi/mysql.conf

OK - this is as far as I feel able to go. Maybe some akonadi or
apparmor specialist can take over from here?


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages akonadi-server depends on:
ii  akonadi-backend-mysql  4:17.08.3-1
ii  libc6  2.25-5
ii  libgcc11:7.2.0-18
ii  libkf5akonadiprivate5  4:17.08.3-1
ii  libkf5akonadiwidgets5  4:17.08.3-1
ii  libkf5configcore5  5.37.0-2
ii  libkf5coreaddons5  5.37.0-2
ii  libkf5crash5   5.37.0-2
ii  libkf5i18n55.37.0-2
ii  libqt5core5a   5.9.2+dfsg-6
ii  libqt5dbus55.9.2+dfsg-6
ii  libqt5gui5 5.9.2+dfsg-6
ii  libqt5network5 5.9.2+dfsg-6
ii  libqt5sql5 5.9.2+dfsg-6
ii  libqt5widgets5 5.9.2+dfsg-6
ii  libqt5xml5 5.9.2+dfsg-6
ii  libstdc++6 7.2.0-18

akonadi-server recommends no packages.

Versions of packages akonadi-server suggests:
ii  akonadi-backend-mysql   4:17.08.3-1
pn  akonadi-backend-postgresql  
pn  akonadi-backend-sqlite  

-- no debconf information