Akonadi broken after upgrade.

[RCheesley]

Problem exists when updating to Kubuntu 14.04 with Akonadi failing to start

I seem to have resolved my akonadi issues, though time will tell. So far, so good. First I tried to mv the ~/.config/akonadi directory, which didn't fix it. Not sure if it contributed to fixing it, though, but it did make me have to reconfigure things again.

Anyways, things seem to be functional after I did this:

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install akonadi-server kubuntu-desktop --reinstall

So I had this problem, which manifested as sflphone hanging with high CPU load, running from command line showed it was falling over due to Akonadi being broken. I followed the steps above (renamed the config dir, then reinstalled) and Akonadi now starts properly, so part 1 in the process appears to be resolved.

Thanks folks!

Ruth

[woodsmoke]

I will confirm that the bug persists as of the date of this post.

The operative problem, I think, from the following discussion at Launchpad is:

If one does not do the "Knotes" migration.

I, unfortunately, did not do that for the following reason:

After years of debate about turning the computer off or leaving it run, I have now opted for turning it off.

The reason for this is because I do "most" of my work on my cellphone.

So, when the upgrade to Trusty popped I did it, it took many hours, and the next day, after the restart, I had to go to the college and just shut down the machine after the restart.

I have done a manual reinstall of Kontact, a manual reinstall of Akonadi, and also did the method provided above using console.

The "possible" PRE-EMPTIVE fix is that anyone reading this thread and is going to do the upgrade to Trusty to actually DO the knotes migration.

Unless the "migration" thing was part of the problem to begin with.

ANCILLARY ATTEMPTS:

I removed my e-mail clients, gmail, the college and yahoo all of which were working in Saucy and it did not help.

In the link below there is mention of manually editing a database, this may or may not work so,,,,

Somebody might attempt a manual edit:

Experienced this issue upgrading from Kubuntu 13.10 to 14.04; Akonadi DB probably goes back to Kubunnto 12 era :
mysql> DELETE FROM PartTable WHERE name='GID';
Query OK, 48 rows affected (1.12 sec)

https://bugs.launchpad.net/ubuntu/+s...i/+bug/1290717

The problem there is that of the uninitiated finding the particular database and editing using the console therein.

So, if someone with vastly more experience would care to post a NON-cryptic post with complete step by step directions then maybe someone could try it.

A SIDE NOTE:

I was surprised to see that Akonadi only has the one option of "starting or stopping".

is it possible that this subsuming of code into other parts of Akonadi is part of the problem?

woodsmoke

The following fixed the issue for me

mysql --socket=/home/user/.local/share/akonadi/socket-pippo/mysql.socket

username is "user" and the hostname is "pippo".

mysql> use akonadi;
mysql> DELETE FROM PartTable WHERE name = 'GID';

An easy solution worked for me

[SteveRiley]

Good idea! But how is it done?

1. Open a console window and run

akonadictl stop

2. Follow my steps in post #12

3. Run

sudo apt-get install akonadi-backend-postgresql

4. While still in the console window, type

kcmshell4 kcm_akonadi

In the window that opens, click the Akonadi Server Configuration tab. In the Database driver dropdown, choose PostgreSQL.

5. Near the bottom right corner of the window, click Start. Then click OK.

6. Recreate your resources.

[pnunn]

Keep an eye on it. I have to disable indexing of email or virtuose_t goes postal, pegs two cup's and throws segfault messages all over the syslog.

Peter.

[ContextSwitch]

Hm... Akonadi has been rock solid here for some time now, not sure what else to say as I haven't had to embark on any troubleshooting of my own in ages.

Due to a few other little peculiarities that seem to be creeping out of the woodwork I decided to go with a clean, fresh, brand spanking new home directory and now akonadi seems to be ok (fingers crossed).

I've been running Linux since 1999, been through a lot of different distros, and since then I've reset my home directory only once before today and that was on the transition from KDE 3 to KDE 4. Things seem to be running a lot smoother now and the fonts have improved as well. One thing I noticed immediately was how fast akonadi nepomuk now is when starting from scratch.

[zeron00]

Idea: switch the back end to PostgreSQL.

Good idea! But how is it done?

[SteveRiley]

Hm... Akonadi has been rock solid here for some time now, not sure what else to say as I haven't had to embark on any troubleshooting of my own in ages.

Idea: switch the back end to PostgreSQL. I have heard of sporadic instances where different databses work better for different people. I'm not aware of any specific cause-effect relationships. But it might be a useful test for you to try.

[ContextSwitch]

So much for my theory ... I just had akonadi fail on login with session management switched off.

Ahh well ...

[ContextSwitch]

One of the first things I do on any KDE install is to change the session management configuration to always start with an empty session on login. And I am not experiencing any of the Akonadi-related problems you describe. I cannot predict whether there might be a cause-effect relationship here, but it wouldn't hurt for you to test.

Yeh, cheers Steve, I'm going to do that for now as a work-around although I do like have the previous session restored, ahh well, I only like it coz I'm lazy!

Also, you can force a complete Akonadi rebuild with the following commands. Do this when not logged into KDE.

rm -rfv ~/.config/akonadi/*

rm -rfv ~/.local/share/akonadi/*

rm -rfv ~/.kde/share/config/akonadi*

Note the lack of a / before the * in the last command.

I've tried these except the .config one as I didn't want to go through the hassle of re-creating all my e-mail settings, etc. Because akonadi does work (most times) I decided it has to be something else. I'm now pretty sure it's caused by starting kontact early in the log-in sequence but I haven't looked any deeper into it.

[alez]

Excuse me, it sure is confusing. I still have the problem.
@ SteveRiley apparently moving ~/.config/akonadi didn't work. Also there's the matter of having to reconfigure everything again. Of course if that means it will be fixed why not

[SteveRiley]

The upshot of this is that when I restart a session kontact is restarted automatically through session management.

One of the first things I do on any KDE install is to change the session management configuration to always start with an empty session on login. And I am not experiencing any of the Akonadi-related problems you describe. I cannot predict whether there might be a cause-effect relationship here, but it wouldn't hurt for you to test.

Also, you can force a complete Akonadi rebuild with the following commands. Do this when not logged into KDE.

rm -rfv ~/.config/akonadi/*

rm -rfv ~/.local/share/akonadi/*

rm -rfv ~/.kde/share/config/akonadi*

Note the lack of a / before the * in the last command.

[ContextSwitch]

Thanks alez, your experience seems to confirm mine, I may raise a bug but I think I'd like to get a few more tests done first.

For the sake of accuracy when you say

I had a similar problem with kmail.

You "had" a problem meaning that you have fixed it or you still have the problem?

[alez]

I had a similar problem with kmail. If i left kmail open when I log out (so it starts automatically on my next log in) akonadi will fail to start. If i close everything and start a fresh session, kmail and akonadi start without a problem so guess it's really a timing problem