| Summary: | Multiple MySQL table structure errors | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] Akonadi | Reporter: | Peter Humphrey <peter> |
| Component: | server | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | major | CC: | Martin, peter, raphael.cazenave |
| Priority: | NOR | ||
| Version: | 1.13.0 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
akonadictl start output
.local/share/akonadi/db_data/mysql.err grep akonadi .xsession-errors |
||
|
Description
Peter Humphrey
2015-05-31 10:22:06 UTC
Hello Peter, thank you for your report. I have no idea what it can be, but I ask some questions: 1) Is this really a new user, i.e. means ~/.config/akonadi and ~/.local/share/akonadi and ~/.kde/share/config/akonadi* do not exist? 2) Are you sure that only one mysqld is running? I have seen it several times that after an akonadictl stop mysqld was not stopped properly at least not within a minute. When doing an akonadictl start while old mysqld is running, it unfortunately starts another. I ask due to: 150531 10:54:57 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction But there is another message about another mysqld running missing from the log. 3) Are you positive that your filesystem is 100% clean? Review syslog/messages log and/or dmesg for any errors of the filesystem and any errors of the underlying backend storage. Please do an fsck -N (no modify, read only mode) on the unmounted filesystem as well, just to make sure it is intact. Please also state what filesystem type / device the Akonadi stuff is located on. 4) When you start akonadi on a terminal with akonadictl start do you see any additional messages or errors? You may also review ~/.xsession-errors for any additional errors. 5) Any errors in ~/local/share/akonadi/akonadiserver.error and/or akonadi_control.error? 6) Last also: Did you do a MySQL upgrade between creating the user and starting Akonadi for the first time (thus creating the database) and your import of old mails? If so, it may be needed to run mysql_upgrade on the database. I ask due to: 150531 10:29:56 [ERROR] Native table 'performance_schema'.'events_statements_current' has the wrong structure Also what exact patch release of Akonadi 1.13 is it? Does it contain any of the performance related improvements from Akonadi 1.13 git branch? I have used them for a long time, but the Debian developer who packaged 1.13 had issues with it. Also please state what version of KDEPIM you use on top on Akonadi. You may also want to try with Akonadi 15.08 or even later, but you need Qt 5 based KDEPIM for that as well, so also Plasma 5 instead of KDE SC 4.14/4.11 stuff. I have KDEPIM/Akonadi running from git master together with MariaDB 10 and mysql.err is clean. Oh, I now found you reported it in May already. So in case that issue was interim and is fixed meanwhile, please state so, so I can close the bug. Sorry for taking long time to reply to bug report. The KDEPIM team needs more people to do bug triaging. Created attachment 95433 [details]
akonadictl start output
Created attachment 95434 [details]
.local/share/akonadi/db_data/mysql.err
Created attachment 95435 [details]
grep akonadi .xsession-errors
Hello Martin,
Thanks for your reply - with its long list of questions!
0. First, I don't have any other PIM components installed than KMail - could all these errors be caused by not having a more complete set of programs? My machine runs Gentoo stable. It has two 1TB SSDs (Crucial) arranged in RAID-1 using mdadm, and all my user stuff is in /dev/md7 (ext4) which is on /dev/sd[ab]7. I've just rebooted without another MySQL instance running and with a clean .xsession-errors.
1. I was having various problems with KMail at the time, which were fixed temporarily by archiving all my mails, creating a new user, importing the mails and thus starting again. I mentioned the new user to show that I was starting with a clean slate.
2. I did have MySQL starting at boot time as a general service. I've discontinued that now to avoid red herrings here.
3. I've run fsck many times, and I'm sure the file-systems are as clean as I can get them.
4. See attached files.
5. akonadiserver.error and akonadi_control.error don't exist here.
6. MySQL has been at version 5.6.27 ever since it became available in Gentoo stable.
This is the history of akonadi. My record only goes back to June, as you see:
$ genlop akonadi-server
* app-office/akonadi-server
Mon Jun 29 15:45:10 2015 >>> app-office/akonadi-server-1.13.0
Fri Aug 7 09:08:25 2015 >>> app-office/akonadi-server-1.13.0-r1
Sun Oct 25 08:56:49 2015 >>> app-office/akonadi-server-1.13.0-r2
No higher versions are available in Gentoo. I've built a separate, experimental KDE system using Qt-5 and the Gentoo plasma profile and kde overlay. Do you want me to do some more testing in that system? It still has the same version of akonadi-server though. I could install the whole of KDE-PIM in that system in a few days' time, once the overlay is consistent again.
Peter, I reviewed your files. I have no clue at whats happening here. Basically if you really start without ~/.local/share/akonadi and ~/.config/akonadi directories, i.e. clean from scratch, Akonadi starts a new mysqld from and creates the database from scratch. I am not sure whether your logs reflect that state. Maybe redo the logs with the following conditions: - akonadictl stop - make sure mysqld process is gone - remove or move away ~/.config/akonadi - remove or move away ~/.local/share/akonadi - remove or move away ~/.kde/share/config/akonadi* (and maybe even kmail*rc) - akonadictl start on console: Capture output of it. - look whether mysql.err exists and include it exactly in the state after the first start of Akonadi after you removed everything According to trying with newer versions: You can try. But then I´d recommend to use at least KDEPIM and Akonadi 15.08. That said, Debian Jessie has 1.13 with *some, but not all* of the newer performance related patches after last release of 1.13 from the git 1.13 branch of Akonadi. As said, the maintainer who made the 1.13 patches had issues with some of the patches after the last release of 1.13. That said the performance table is a MySQL specific thing. So I wonder how it can have the wrong structure. Thats all I can come up with for now. Good luck. Well, that's odd. I've just gone through the whole process of creating a new user account and importing the mail archive from the old one - and now I don't get any errors at all! Well, I did get 10 instances of this during the import process: [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction but nothing since then. It looks as though the problem has been fixed. It must have been hiding in the data somehow, though I can't imagine how. Anyway, do feel free to close the bug, Martin. Thanks for your time - and apologies for wasting it! Thanks. Closing. To me this deadlock thing still hints at that at some time two mysqld has been running. Well if it works for you now, all the better. Feel free to reopen if you see this again. Sorry, I meant to close it. |