bovender wrote:I think I finally solved it! Kind of by accident, and I still don't know what the cause was.

Code: Select all

$ sudo service apparmor teardown
$ sudo service apparmor start


(NB: systemctl cannot handle the `teardown` task)

Now akonadi works again!

I saw your comment on the bug report and tried the above commands, and they worked fine. Then I came over here and got caught up, and added

Code: Select all

/sys/devices/system/** r,

though it didn't seem to make a difference.

So, akonadi & kmail work after your teardown and restart, but if I reboot my machine, akonadi doesn't and can't start:

Code: Select all

username@desktop:~$ akonadictl status
Akonadi Control: stopped
Akonadi Server: stopped
Akonadi Server Search Support: available (Remote Search, Akonadi Search Plugin)
Available Agent Types: akonadi_akonotes_resource, akonadi_archivemail_agent, akonadi_birthdays_resource, akonadi_contacts_resource, akonadi_davgroupware_resource, akonadi_ews_resource, akonadi_ewsmta_resource, akonadi_facebook_resource, akonadi_followupreminder_agent, akonadi_googlecalendar_resource, akonadi_googlecontacts_resource, akonadi_ical_resource, akonadi_icaldir_resource, akonadi_imap_resource, akonadi_indexing_agent, akonadi_kalarm_dir_resource, akonadi_kalarm_resource, akonadi_kolab_resource, akonadi_maildir_resource, akonadi_maildispatcher_agent, akonadi_mailfilter_agent, akonadi_mbox_resource, akonadi_migration_agent, akonadi_mixedmaildir_resource, akonadi_newmailnotifier_agent, akonadi_notes_agent, akonadi_notes_resource, akonadi_openxchange_resource, akonadi_pop3_resource, akonadi_sendlater_agent, akonadi_tomboynotes_resource, akonadi_unifiedmailbox_agent, akonadi_vcard_resource, akonadi_vcarddir_resource

username@desktop:~$ akonadictl start
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
username@desktop:~$ 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-akonadi"
org.kde.pim.akonadiserver: arguments: ("--defaults-file=/home/username/.local/share/akonadi/mysql.conf", "--datadir=/home/username/.local/share/akonadi/db_data/", "--socket=/run/username/1000/akonadi/mysql.socket", "--pid-file=/run/username/1000/akonadi/mysql.pid")
org.kde.pim.akonadiserver: stdout: ""
org.kde.pim.akonadiserver: stderr: "mysqld-akonadi: [ERROR] Could not open required defaults file: /home/username/.local/share/akonadi/mysql.conf\nmysqld-akonadi: [ERROR] Fatal error in defaults handling. Program aborted!\n"
org.kde.pim.akonadiserver: exit code: 1
org.kde.pim.akonadiserver: process error: "Unknown error"
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/run/username/1000/akonadi/mysql.socket' (2)'
Check that mysqld is running and that the socket: '/run/username/1000/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...


(The error message is slightly different now from the one I was getting the other day, probably because the apparmor teardown and restart allowed me to actually get all of akonadi's files & folders re-created by following the Clean Start After A Failed Migration directions)

Anyway, If I use your teardown & restart commands again...

Code: Select all

username@desktop:~$ sudo service apparmor teardown
[sudo] password for username:
 * Unloading AppArmor profiles                                                                                                                     [ OK ]

username@desktop:~$ sudo service apparmor start

username@desktop:~$ akonadictl start
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
username@desktop:~$ org.kde.pim.akonadiserver: Starting up the Akonadi Server...
akonadi.collectionattributetable                   OK
akonadi.collectionmimetyperelation                 OK
akonadi.collectionpimitemrelation                  OK
akonadi.collectiontable                            OK
akonadi.flagtable                                  OK
akonadi.mimetypetable                              OK
akonadi.parttable                                  OK
akonadi.parttypetable                              OK
akonadi.pimitemflagrelation                        OK
akonadi.pimitemtable                               OK
akonadi.pimitemtagrelation                         OK
akonadi.relationtable                              OK
akonadi.relationtypetable                          OK
akonadi.resourcetable                              OK

(etc, etc.)


...everything works fine again, until I shut the machine down, in which case I have to do it all again after starting.

Are you seeing this behavior, too? If not, any idea how you're getting apparmor to do its thing persistently?

Thanks!

dfoskett wrote:/.../ If not, any idea how you're getting apparmor to do its thing persistently?

You can set an AppArmor profile into complain mode. In this mode AppArmor allow access to all files but write violations into syslog. So try

Code: Select all

sudo aa-complain /usr/sbin/mysqld-akonadi

and then check syslog (/var/log/messages or ../syslog or ../autit* or ...) for entries from AppArmor. You should see which file/folder are accessed and with which effective uid and gid mysqld is running. This could be important for read access to ~/.local/share/akonadi/mysql.conf (must be global readable !?)

With

Code: Select all

sudo aa-enforce /usr/sbin/mysqld-akonadi

you bring the profile back in the normal/enforce mode.

Another think ... The profile file for myslq-akonadi includes another file for making local justfications

Code: Select all

# Site-specific additions and overrides. See local/README for details.
 #include <local/usr.sbin.mysqld-akonadi>

Have you checked the contents of this file ?

raphaelra wrote:

Code: Select all

sudo aa-complain /usr/sbin/mysqld-akonadi

I installed apparmor utilities but when I run this command i get an strange error - still reading up on it, but if you have any hints or pointers...?

Code: Select all

ERROR: Include file /etc/apparmor.d/abstractions/dri-enumerate not found

This

https://gitlab.com/apparmor/apparmor/bl ... -enumerate

purports to be that file, so I created it, and now get the error

ERROR: Include file /etc/apparmor.d/abstractions/mesa not found

ugh. i'll keep going, but this is crazy. does an akonadi migration modify apparmor to this degree? I think I'll file the bug report again, see if they'll fix whatever's wrong.

raphaelra wrote:This could be important for read access to ~/.local/share/akonadi/mysql.conf (must be global readable !?)

Yeah, it's globally readable.

raphaelra wrote:Another think ... The profile file for myslq-akonadi includes another file for making local justfications

Code: Select all

# Site-specific additions and overrides. See local/README for details.
 #include <local/usr.sbin.mysqld-akonadi>

Have you checked the contents of this file ?

This file doesn't exist, assuming "local" means home/username/.local - but everything in my main file seems to match yours and bovender's...?

UPDATE: i had to create 6 new files in /abstractions, and then

Code: Select all

sudo aa-complain /usr/sbin/mysqld-akonadi

finally ran with no errors, and akonadi was running automatically when i rebooted. Thanks VERY much for all your help! I'll write all this up as a bug and leave it open so hopefully no one will have to bother this this again after they release the next bunch of fixes/updates.

double posted, sorry, not sure how to delete this

double-posted, sorry - not sure how to delete this

dfoskett wrote:

raphaelra wrote:Another think ... The profile file for myslq-akonadi includes another file for making local justfications

Code: Select all

# Site-specific additions and overrides. See local/README for details.
 #include <local/usr.sbin.mysqld-akonadi>

Have you checked the contents of this file ?

This file doesn't exist, assuming "local" means home/username/.local - but everything in my main file seems to match yours and bovender's...?

"local" means /etc/apparmor.d/local. The idea is not to edit config files contained in packages (because the changes may lost after package update), but include a file where the user can make (local) changes.

dfoskett wrote:UPDATE: i had to create 6 new files in /abstractions, and then /.../ akonadi was running automatically when i rebooted.

I'm happy, it is running, but not sure, if the profile is automaticaly activated (in enforce mode) after reboot. You can check this with sudo aa-status. You should see in the output

Code: Select all

0 profiles are in complain mode.

It's looks like your AppArmor setup is a little bit "entangled". Maybe it's because of the newer kernel

Ah, okay. /etc/apparmor.d/local/usr.bin.mysqld-akonadi is empty. I'm not sure what I would put there, the contents of the main usr.bin.mysqld-akonadi seem to match yours and the OP's, so I'm not sure what's wrong. And yes, it's in complain mode, that's what's enabling akonadi to start on boot, saving me from having to teardown and restart apparmor every time i turn on my PC:

Code: Select all

username@desktop: sudo aa-status

...

1 profiles are in complain mode.
   /usr/sbin/mysqld

Still no idea what's wrong, but at least it's working.

dfoskett wrote:...everything works fine again, until I shut the machine down, in which case I have to do it all again after starting.

Are you seeing this behavior, too? If not, any idea how you're getting apparmor to do its thing persistently?

Sorry for my silence in the last couple of days. I finally got around to rebooting my machine, and yes, the error occurred again. Haven't yet had the time to test the things that you found out in the mean time.

dfoskett wrote:

Code: Select all

1 profiles are in complain mode.
   /usr/sbin/mysqld

Still no idea what's wrong, but at least it's working.

It's not really working ... When in complain mode, AppArmor does not block mysqld from starting, but reports any violation to syslog. AppArmor does't care abount mysql in this moment. You shoud now look in the syslog what AppArmor is reporting there.

If you activates the profile with "sudo aa-enforce /usr/sbin/mysqld-akonadi", mysqld will propably not start.

Here's what I see in /var/log/syslog after putting the mysqld-akonadi profile into complain mode and restarting akonadi:

Code: Select all

audit: type=1400 audit(1566844026.762:83): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/mysqld" pid=29043 comm="apparmor_parser"
audit: type=1400 audit(1566844066.014:84): apparmor="ALLOWED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/" pid=29561 comm="mysqld-akonadi" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit: type=1400 audit(1566844066.014:85): apparmor="ALLOWED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/node0/meminfo" pid=29561 comm="mysqld-akonadi" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit: type=1400 audit(1566844066.026:86): apparmor="ALLOWED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/" pid=29562 comm="mysqld-akonadi" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit: type=1400 audit(1566844066.026:87): apparmor="ALLOWED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/node0/meminfo" pid=29562 comm="mysqld-akonadi" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit: type=1400 audit(1566844066.030:88): apparmor="ALLOWED" operation="open" profile="/usr/sbin/mysqld" name="/home/[REDACTED]/.local/share/akonadi/mysql.conf" pid=29562 comm="mysqld-akonadi" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
audit: type=1400 audit(1566844066.182:89): apparmor="ALLOWED" operation="mknod" profile="/usr/sbin/mysqld" name="/home/[REDACTED]/.local/share/akonadi/db_data/[REDACTED].lower-test" pid=29562 comm="mysqld-akonadi" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
audit: type=1400 audit(1566844066.182:90): apparmor="ALLOWED" operation="open" profile="/usr/sbin/mysqld" name="/home/[REDACTED]/.local/share/akonadi/db_data/[REDACTED].lower-test" pid=29562 comm="mysqld-akonadi" requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=1000
audit: type=1400 audit(1566844066.182:91): apparmor="ALLOWED" operation="unlink" profile="/usr/sbin/mysqld" name="/home/[REDACTED]/.local/share/akonadi/db_data/[REDACTED].lower-test" pid=29562 comm="mysqld-akonadi" requested_mask="d" denied_mask="d" fsuid=1000 ouid=1000
audit: type=1400 audit(1566844066.182:92): apparmor="ALLOWED" operation="mknod" profile="/usr/sbin/mysqld" name="/home/[REDACTED]/.local/share/akonadi/db_data/[REDACTED].lower-test" pid=29562 comm="mysqld-akonadi" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
audit: type=1400 audit(1566844066.182:93): apparmor="ALLOWED" operation="open" profile="/usr/sbin/mysqld" name="/home/[REDACTED]/.local/share/akonadi/db_data/[REDACTED].lower-test" pid=29562 comm="mysqld-akonadi" requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=1000


(I clipped the first characters from each line which contained the timestamp, which does not seem to matter here. User and machine names are redacted.)

I do not understand why read access to /home/[REDACTED]/.local/share/akonadi/mysql.conf is denied even when it should be permitted by the line

Code: Select all

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


in /etc/apparmor.d/usr.sbin.mysqld-akonadi

It's looks good. AppArmor allows all access mysqld needs (apparmor="ALLOWED"). Time to bring the profile /usr/sbin/mysqld-akonadi in enforce mode and check, if akonadi starts ...

Hm. When I `aa-enforce` the mysqld-akonadi rules, akonadi keeps running. But after a reboot, it won't start again. I'll keep the rules in complain mode for now...

Strange AppArmor says, it allows access to all files and then stil blocks someting. What was reported to syslog after aa-enforce and reboot ?

bovender wrote:Hm. /.../ I'll keep the rules in complain mode for now...

Hm, you can delete or disable the profile at all

bovender wrote:

dfoskett wrote:...everything works fine again, until I shut the machine down, in which case I have to do it all again after starting.

Are you seeing this behavior, too? If not, any idea how you're getting apparmor to do its thing persistently?

Sorry for my silence in the last couple of days. I finally got around to rebooting my machine, and yes, the error occurred again. Haven't yet had the time to test the things that you found out in the mean time.

Same problem here. Any solution?

erasmoc wrote:Same problem here. Any solution?

So far just the apparmor hack discussed above. Lets you use akonadi, lets it start when your machine starts, but isn't really a "solution".