Bug 361157

Possibly related:
After performing the same upgrade on Leap, I'm seeing "The Akonadi personal information management service is not operational" in any program that uses Akonadi, but I haven't seen this particular crash.

It was working before the upgrade, and the Leap install was a fresh one, not an upgrade, so no generations old data to deal with.

After running "akonadictl fsck" it's still "not operational".  Running "akonadictl stop" doesn't stop anything.  The MySQL instance was up - at least the Workbench connected to it (and complained about a MySQL version mismatch).

If somebody can confirm that the combination FW5.20/Plasma5.6/Qt5.6 is known to work for Akonadi, we may be able to narrow it down to either a local configuration problem or a distribution-specific problem.

I have the same status as S. Bryant.

Additional to the crash I get the same Message "The Akonadi personal information management service is not operational" in all programs working with Akonadi, and there seems to be no solution to it. 
Some indications:
This happens even in an fresh ("virgin") installation, so it's not a config error.
Looks like either akonadi hangs somehow, or the communication with kontact doesn't work. 
akonadictl stop doesn't work - akonadictl start gives "akonadi already running".
Akonadiconsole starts up (after long wait), but gives the same message as above.
Reverting the akonadi/kontact bunch packages to leap standard repositories doesn't change situation.
I'm in discussion with moderator wolfi323 from Opensuse formus, who told me:
"the same combination (Qt 5.6.0 from KDE:Qt5, KDE Frameworks 5.20.0 from KDE:Frameworks5, Akonadi and KDEPIM5 from KDE:Applications) fine here on my 13.2 system.
There is one difference though: KDE:Applications is built against KDE:Qt5 for 13.2, but not for Leap, so the Leap packages are actually built against Qt 5.5.1.
Should not cause a problem normally, but who knows...
Although this only affects the kdepim packages and not Akonadi, because Akonadi hasn't been updated (and therefore being rebuilt) since Qt 5.6.0 has been released I think."

So this looks like something confined to leap, but that'S all I can say by now ...

My system: opensuse Leap (64 bit)

Yesterday I've updated my system in the same way (Qt 5.6.0 from KDE:Qt5, KDE Frameworks 5.20.0 from KDE:Frameworks5, Akonadi and KDEPIM5 from KDE:Applications 16.03)  and it worked fine. 

Today I installed the suggested updates  and system stops working. Same behavior as described here. If I call  'akonadi_ctrl stop' nothing happens. If I start a single applications instead of kontact the same behavior.  If I start kmail using the konsole I got the error klauchner failed due to unknown protocol 'cid'. I'm not sure if this is related to cited error.

I checked if there is no package mismatch and all seems to be okay.

At the end all programs using akonadi don't start.  For me this seems to be a very fragile combination of KDEPIM and akonadi in opensuse leap.

The following packages installed today:
kdgantt2|16.03.90-4.1               
libKF5Libkdepim5|16.03.90-5.1       
libkleo|16.03.90-3.1                
libKF5KDGantt2-5|16.03.90-4.1       
libkdepim|16.03.90-5.1              
libKF5Libkleo5|16.03.90-3.1         
libKF5MailImporter5|16.03.90-3.1    
kleopatra5|16.03.90-4.6             
libavutil55|3.0.1-66.1              
libpostproc54|3.0.1-66.1            
libswresample2|3.0.1-66.1           
libavresample3|3.0.1-66.1           
libswscale4|3.0.1-66.1              
libavcodec57|3.0.1-66.1             
libavformat57|3.0.1-66.1            
libavfilter6|3.0.1-66.1             
libopencv3_1|3.1.0-83.7             
handbrake-gtk|0.10.5-1.6            
libavdevice57|3.0.1-66.1            
ffmpeg|3.0.1-66.1|x86_64            
grantlee5|5.0.0-7.2|x86_64          
libKF5PimCommon5|16.03.90-4.1       
grantleetheme|16.03.90-3.1          
knotes5|16.03.90-58.5|x86_64        
libksieve|16.03.90-5.1|x86_64       
libKF5Gravatar5|16.03.90-3.1        
libKF5GrantleeTheme5|16.03.90-3.1   
kdepim-apps-libs|16.03.90-3.1       
kontact5|16.03.90-58.5|x86_64       
kaddressbook5|16.03.90-58.5         
messagelib|16.03.90-6.1             
akregator5|16.03.90-58.5            
libKF5MailCommon5|16.03.90-3.1      
korganizer5|16.03.90-58.5           
kmail5|16.03.90-58.5                
akonadi_resources|16.03.90-58.5    
kdepim-addons|16.03.90-8.1         
kdepim|16.03.90-58.5

I have to come back to this, because after installing the 16.04 Version of KDE Apps (with Akonadi and the full kontact-Package) the situation is not resolved and seemingly far from being so. 

Akonadi does not work properly, as reported by all akonadi-dependent applications and akonadiconsole. And as can be seen here and in the Opensuse-forum (here: https://forums.opensuse.org/showthread.php/516850-After-Updating-KDE-FW-to-5-20-and-Plasma-to-5-6-(with-Qt-to-5-6-as-well)-Akonadi-quot-doesn-t-work-quot) I am not the only one with this problem. The fact that I am not able to use kontact, which worked properly before 16.03.90-x, and in consequence have no access to most of my mails is quite unbearable, because I do my business using this software.

The crucial question for me is: Am I dealing with a software bug here, or does it look more like a mere config related problem? And if its a bug, when is it going to be resolved?

And the second question then is: if it is a config-problem which part of the akonadi and kontact configuration do I have have to and may safely erase, while preserving my emails (which are in a seperate dir), since - unfortunately - not all backups of them are really current (most are, but since akonadi was broken quite surprisingly, I had no chance to do backups manually. Interestingly, the kmail backup-assistant worked even after akonadi broke, so I'm hopefull that there might be a chance even for the Mails that I had not included into my frequent backups (which I am going to change now)).

To nail down the problem I war able to get some Info out of my system, which I attach as text-files:

1. an akonadi selftest report a few days ago (when V.16.04 was NOT installed (and please don't ask me, how to do it again))

2. The feedback of an akonadiconsole start today AFTER installing V.16.04, which I collected in konsole. Here is how I did that (just for info):

- starting kontact ==> "not working properly"
- starting akonadiconsole ==> same result, stopping/killing akonadiconsole
- killing all akonadi-related processes and all kontact processes
- starting akonadiconsole again, feedback collected in Textfile

Would be nice if someone had a look at it, and tell me, what to do.

Thanks a lot.

Created attachment 98548 [details]
Resullt of akonadi selftest BEFORE 16.04, with plasma 5.6.2, KDE FW 5.21,

See my last comment.

Jay

Created attachment 98549 [details]
Feedback from akonadiconsole, after installing KDE Apps 16.04

See my last Comment.

Jay

In the forum thread I mentioned above (see Comment 4) have today (25.042016) been two posts by user opuetz (Nr. 36 & 37) who obviously has been testing different combinations of FW/Plasma/Apps Versions which might be helpful.

In the forum thread I mentioned above (see Comment 4) have today (25.042016) been two posts by user opuetz (Nr. 36 & 37) who obviously has been testing different combinations of FW/Plasma/Apps Versions which might be helpful.

WOW! NIce Try! Changing a bug from critical - for all those who are bugged by it - to normal doesn't make it go away, but makes it easier for you to deal with it as "unimportant" and leave everything as it is. ... Interesting way of dealing with user complains, Mr. Giboudeaux. 

Thanks a lot!!!

Critical for you it's not necessary a critical bug.
I don't understand this bug. 
It's show a akregator backtrace and we spoke about akonadi ?
It's bug is fixed in 5.2

Sorry, Mr. Montel,

have you read the posts or not? Akregator was the start of it, but since this happened,  Akonadi is not working, as can be seen in the following posts. The Akonadi problem might be related, maybe its not. The Akregator crash might just be collateral, because right now Akregator is working fine, since its not depending on Akonadi ( which is not very surprising). I just can't make it out, but its not only me having this problem, there are more people, as you can see from the other posts here, and there are even more in the opensuse forum thread (see comment 4) where seeking for a solution wasn't successful either (just take a look, if you please). All I do, is trying to help, because I do my business with Kontact and have no access to some of my mails since then. 
So for me, and maybe others, this bug is fatal. 
All I want to know if it is a config problem, which I can solve by starting from scratch, or if it is a bug that needs your attention. For it looks like the latter, because starting akonadi as a virgin user does not solve the problem. All I (we) can do is providing data, not interpreting it. 
I know that there is lots of things you have to do, but in the it doesn't help if the software is not usable, does it?

Thanks  lot for your help

Same bug as mine (https://bugs.kde.org/show_bug.cgi?id=362044, do not know how to report duplicates).

My temporary fix: akonadictl fsck, kill all akonadi processes, akonadictl fsck (then in total all my > 4000 mails are gone), kill all akonadi processes again, start kontact (if it does not work, try again). Works until the system is rebooted (or X got killed). All mails are redownloaded and - in the beginning all, later only part of them - folders (as trash or inbox) are assigned to wrong folders (even linked to other mail accounts, or inbox is now trash and vice versa).

What I noticed/might be important: 
- akonadictl stop nor restart do anything!
- pressing the button for more details about akonadi not running properly within kontact does not do anything
- I'm running 4x pop, 2x imap, google contacts and calendar and email resources.
- as long as I do not restart everything seems to work flawlessly (as long as I did not forget to reassign on of the folders correctly)
- sometimes killing all akonadi processes leads to freazing of kde needing a soft reset.
- searched a lot and really seems to be concentrated on the previously mentioned Opensuse combination.
- completely lost my emails from one account (probably after running akonadictl vacuum)
- akonadictl fsck removes all of my ressources and probably all of my emails!!!
- Even using the restart-button within the kontact setting for the accounts does not harm and resources still seem to run fine.

Would changing status to confirmed make sense? Even if it only seems related to one distro with one repository?

I have this bug too... I installed:

openSUSE Leap.
Qt 5.6
Plasma 5.6.3
KDE apps 16.04
Kmail 5.2

This bug isn't fixed...

Same for me. Same package combination as Erick.

Sometimes it works if I logout an re-login. Sometimes not. Sometimes it works if I reboot sometimes not. This is a crude and critical bug because it makes it impossible to use Kontakt. I do my daily work with Kontact.

If the first try failed nothing helps beside logout or reboot.

Bug isn't fix.

Same for me. Same package combination as Erick.

Sometimes it works if I logout an re-login. Sometimes not. Sometimes it works if I reboot sometimes not. This is a crude and critical bug because it makes it impossible to use Kontakt. I do my daily work with Kontact.

If the first try failed nothing helps beside logout or reboot.

Bug isn't fix.

Has somebody alread upgraded to KDE apps 16.04.01 and checked whether the SIGSEGV still occurs? I tried to follow the root cause of the memory corruption, but after the update got pulled in, I cannot reproduce it with a number of `akonadictl restart' calls. Can somebody please check?

Has somebody alread upgraded to KDE apps 16.04.01 and checked whether the SIGSEGV still occurs? I tried to follow the root cause of the memory corruption, but after the update got pulled in, I cannot reproduce it with a number of `akonadictl restart' calls. Can somebody please check?

Hello again --- Good to see I am not the only one with this problem, with which I had a few interesting days (up to today ...).
After installing Framework 5.22 and Plasma 5.6.4 and a restart akonadi miraculously started working again (I swear, I didn't change anything in my config). I had - finally - the time to move my emails to my imap server. Took some time, though, but now I have access to everything through thunderbird (which in my is hot quite as powerful as kontact would be). Because ... after installing KDE Apps 16.04.1 and some further tweaking on my side (see the following points) all the splendour has vanished again... but not directly - a few strange things happened:
1. After I changed the Inboxes of my external Email-Accounts to the Inbox of the IMAP Server, the complete local-mail folder structure "disappeared" (from kontact - it still exists on my harddrive) for no apparent reason. I later found out that there had been created an new ".local-mail" folder without me requesting it. I can live with that for now, but would really like to know how that happens, and why.

2. Interestingly my calendars and contacts where completely gone from kontact (and akonadi) - not the data, but all the configs, which makes sense in the light of the following:

3.  As I have my calendars and my contacts on a dav-server (Owncloud at my hosting provider, which has been working like a charm until the problem with akonadi/kontact started (and still does, as far as my mobile devices are concerned), I wanted to keep it that way, but move to the builtin servers on my synology nas. This seemed to be working fine (with some minor glitches which I would have tolerated), but when I was "nearly done", (having my calendars working and imported my contacts) as something "blocked" plasma (I could not switch programs or anything) and I had to reboot the system. After that, I was back with my friend "akonadi not working properly" and had to return to Thunderbird as my PIM system (which is not my first choice for numerous reasons).

My "educated guess" now is, that there is something wrong with the akonadi infrastructure for korganizer/kaddressbook, not necessarily with relation to the DAV subsystem (since this seems to have worked). 
But that´s just a guess. Maybe all this is still just a config problem, but to solve it, I would like to start from scratch for a test (at least everything seems to work "in principle"). Which parts of the akonadi data an the config do I have to delete for that??

Thanks, still, for your help.

Jay

Ok, so I gather that the Akonadi service is not starting for you. I recommend you run Akonadi from terminal (akonadictl start) and look at the output, that usually tells where the problem is.

You can increase the debugging level by running

QT_LOGGING_RULES="* = true
qt.* = false" akonadictl start

(note the newline after true, that's not a typo)

Apologies for cross-post from openSUSE forums

This is on a fresh install of Tumbleweed 20160525 on a new disk and a restored $home from openSUSE 13.2

Opening kmail fails, and starting from the start gives me this  


[Code]
c...a@linux-6dbk:~> akonadictl start
Starting Akonadi Server...
   done.
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
christina@linux-6dbk:~> QCommandLineParser: option not defined: "start-without-control"
search paths:  ("/home/c...a/bin", "/usr/local/bin", "/usr/bin", "/bin", "/usr/bin/X11", "/usr/games", "/usr/sbin", "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin")
Found mysql_install_db:  "/usr/bin/mysql_install_db"
Found mysqlcheck:  "/usr/bin/mysqlcheck"
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
Error    : Table 'akonadi.relationtable' doesn't exist in engine
status   : Operation failed
akonadi.relationtypetable
Error    : Table 'akonadi.relationtypetable' doesn't exist in engine
status   : Operation failed
akonadi.resourcetable                              OK
akonadi.schemaversiontable                         OK
akonadi.tagattributetable                          OK
akonadi.tagremoteidresourcerelationtable           OK
akonadi.tagtable                                   OK
akonadi.tagtypetable                               OK
mysql.column_stats                                 OK
mysql.columns_priv                                 OK
mysql.db                                           OK
mysql.event                                        OK
mysql.func                                         OK
mysql.gtid_slave_pos
Error    : Table 'mysql.gtid_slave_pos' doesn't exist in engine
status   : Operation failed
mysql.help_category                                OK
mysql.help_keyword                                 OK
mysql.help_relation                                OK
mysql.help_topic                                   OK
mysql.host                                         OK
mysql.index_stats                                  OK
mysql.innodb_index_stats
Error    : Table 'mysql.innodb_index_stats' doesn't exist in engine
status   : Operation failed
mysql.innodb_table_stats
Error    : Table 'mysql.innodb_table_stats' doesn't exist in engine
status   : Operation failed
mysql.ndb_binlog_index                             OK
mysql.plugin                                       OK
mysql.proc                                         OK
mysql.procs_priv                                   OK
mysql.proxies_priv                                 OK
mysql.roles_mapping                                OK
mysql.servers                                      OK
mysql.table_stats                                  OK
mysql.tables_priv                                  OK
mysql.time_zone                                    OK
mysql.time_zone_leap_second                        OK
mysql.time_zone_name                               OK
mysql.time_zone_transition                         OK
mysql.time_zone_transition_type                    OK
mysql.user                                         OK

Repairing tables
test.relationtable
Error    : Table 'test.relationtable' doesn't exist
status   : Operation failed
test.relationtypetable
Error    : Table 'test.relationtypetable' doesn't exist
status   : Operation failed
test.gtid_slave_pos
Error    : Table 'test.gtid_slave_pos' doesn't exist
status   : Operation failed
test.innodb_index_stats
Error    : Table 'test.innodb_index_stats' doesn't exist
status   : Operation failed
test.innodb_table_stats
Error    : Table 'test.innodb_table_stats' doesn't exist
status   : Operation failed
MySQL version OK (required "5.1" , available "10.0" )
Database "akonadi" opened using driver "QMYSQL"
DbInitializer::run()
checking table  "SchemaVersionTable"
checking table  "ResourceTable"
checking table  "CollectionTable"
checking table  "MimeTypeTable"
checking table  "PimItemTable"
checking table  "FlagTable"
checking table  "PartTypeTable"
checking table  "PartTable"
checking table  "CollectionAttributeTable"
checking table  "TagTypeTable"
checking table  "TagTable"
checking table  "TagAttributeTable"
checking table  "TagRemoteIdResourceRelationTable"
checking table  "RelationTypeTable"
"ALTER TABLE RelationTypeTable ADD COLUMN id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY"
"\nSql error: Table 'akonadi.relationtypetable' doesn't exist in engine QMYSQL: Unable to execute query\nQuery: ALTER TABLE RelationTypeTable ADD COLUMN id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY"
Unable to initialize database.
terminating service threads
terminating connection threads
stopping db process
Application 'akonadiserver' exited normally...

[/code]

This bug might be related to  bug 363881, and, ultimately, this Qt bug: https://bugreports.qt.io/browse/QTBUG-53957.

Hello,

further development: Since installing Ot 5.6.1, KDE  FW 5.23, Plasma 5.6.95 and Kontact 5.2.2 (in Apps 16.04.2) the Problem seems to be gone. Akonadi/Kontact "survived" several restarts and seems to be working stable again (which actually wasn't the case before). Since I have not changed any of my configurations, there must have been some bug in the apps or in the interplay of the different libs. If I were asked I would suspect something in the address book part of the apps or libs, but that's just a guess.
Sorry, I can't help any further for now, but if the bug crosses my ways again I will certainly report.

Thanks for your help anyway ...

Jay

I've upgraded to Plasma 5.7 (kontact5 16.04.2), and can confirm that the problem is still very much there.  Akonadi (and by extension, all related applications) are still completely unusable on OpenSUSE 42.1.

*** This bug has been confirmed by popular vote. ***

The Bug is still present after an upgrade to Plasma 5.7.5.