Summary: | Akonadi server fails to start right after upgrading to 1.12.0 | ||
---|---|---|---|
Product: | [Frameworks and Libraries] Akonadi | Reporter: | Aitor <mail> |
Component: | server | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED NOT A BUG | ||
Severity: | grave | CC: | dvratil, stephan.menzel |
Priority: | NOR | ||
Version: | 1.12.0 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Aitor
2014-03-29 19:12:06 UTC
Can you please make sure that no MySQL instances are running and that there's no *.lock file in ~/.local/share/akonadi and then try starting Akonadi from console via akonadictl start? If it fails, please provide output from self-test dialog (you will get it by running KMail for example). I might not expressed myself very clearly, sorry. I'll try to clarify what I did try. Once I detected Akonadi was not able to start, I tried to find out what was going on. I was using the default internal MySQL based configuration. With this setup, when I tried to start Akonadi with "akonadictl start", Akonadi failed to boot and at the same time it automatically launched multiple mysqld instances (which might be another bug). At that moment I decided to check the MySQL's data integrity and I started MySQL manually, which did so without any problem. With MySQL booted manually, I decided to change Akonadi's configuration to point it to this manually started instance of MySQL. Akonadi's error message was the same as when it tried to use the default configuration. Mean while I tried with a new clean profile (different user) and I saw that Akonadi booted correctly. At this point, I decided to backup MySQL DB (ask me if you want me to check some data in this DB) and I've wiped the whole .local/share/akonadi folder. Since my data is backed by other servers I have no big problems doing so, but it might be an issue for other people. My Akonadi DB was quite old, so I don't know if that might have been an issue. Unfortunatly, I forgot to backup old akonadiserver.error and akonadi_control.error files, sorry. The only portion of that files available is the one posted in the bug description. Closing, sounds like a problem with MySQL lock or PID not being properly cleaned up after previous shutdown. We cannot cope with that well yet, but there's another report about this somewhere. I'm having the exact same problem here with both akonadi 1.12 and 1.12.1. The only thing that helps is a downgrade to 1.11. My problem description and stacktrace are the same. Also, I can connect to the MySQL server with other tools with no problems. |