I’ve recently switched back to using Kmail in Plasma / 42.3
However, whenever I start Kmail after a boot I get a screen announcing “The Akonadi Perosnal information Management System is not Running. This application cannot be used without it”.
Just under that is a start button. Once entered Kmail works as it should.
Previously when I used Kmail Akonadi would start automatically.
When I stopped using Kmail I uninstalled it. Now I have reinstalled it on the same system and there was no need to reconfigure as all the original config files were still in place… but something seems to have gone wrong with akonadi.
How can I set this up so that akonadi starts on boot / when kmail starts?
As nobody has yet replied, FWIW I never use akonadi and always used to disable the server from starting by setting “StartServer=false” in “akonadiserverrc”.
Maybe see what that’s set to?
karl@erlangen:~> cat .config/akonadi/akonadiserverrc
[Debug]
Tracer=null
%General]
Driver=QMYSQL
[QMYSQL]
Host=
Name=akonadi
Options="UNIX_SOCKET=/tmp/akonadi-karl.nZUOMG/mysql.socket"
ServerPath=/usr/sbin/mysqld
StartServer=true
karl@erlangen:~>
this is my akonadiserverrc
startserver is set to “true”
[Debug]
Tracer=null
%General]
Driver=QMYSQL
[QMYSQL]
Host=
Name=akonadi
Options="UNIX_SOCKET=/tmp/akonadi-farcus.xgYLl6/mysql.socket"
ServerPath=/usr/sbin/mysqld
StartServer=true
from what I understand it is supposed to start when an application needs it . . . but kmail doesn’t seem to be starting it
Checking that was just a passing thought from when I used to disable the server from starting… seemed a little too easy to be the solution.
Sorry, my knowledge of kmail/akonadi is virtually non-existent.
Hopefully you’ll receive a more useful reply.
Upgraded to TW 20171104 a few minutes ago and tested kmail2 5.6.2. With akonadi stopped invoking kmail did start akonadi too. You may want to try: https://wiki.archlinux.org/index.php/KDE#Clean_akonadi_configuration_to_fix_KMail
Not having much luck here.
Followed the instructions to delete all akonadi config files.
Added my mail accounts back in but still having to manually start akonadi on each fresh boot.
Have a look at the akonadi logfiles in ~/.local/share/akonadi. You may have to rebuild the databas, but that’s done by removing / renaming mentioned folder whilst akonadi has not started.
To make sure you start with a really clean config, remove all akonadi traces in ~/.config and ~/.local/share/akondi, and ~/.config/kmail* and ~/.local/share/kmail* and ~/.local/share/kontact/kmail before logging in on the desktop.
With some versions of TW I had to start akonadi manually after booting, but not after graphical login. With TW 20171121 akonadi again starts automatically after booting.
Have you tried simply running
akonadictl start
from the terminal? I don’t use any akonadi applications, but I think that should enable auto start on log in. If not, you can always place the above command in a shell script and save the file in /home/(your user)/.config/autostart-scripts/ which will start the service.
thanks . . . . I’ve tried this but still haven’t made any headway. Despite starting with a super clean config I’m still having to start akonadi manually from within kmail.
Have you tried simply running
akonadictl start
from the terminal? I don't use any akonadi applications, but I think that should enable auto start on log in. If not, you can always place the above command in a shell script and save the file in /home/(your user)/.config/autostart-scripts/ which will start the service.
akonadictl start was one of the initial things I tried when problem first appeared but doesn’t make any difference.
I might have to try it as a startup script.
Yes, KDE KMail2 and Akonadi are not easy but, they usually (99.999 % of the time) “work out of the box” with a “new, fresh” user directory – meaning, before the very first login of the concerned user, the directory contains only what’s in ‘/etc/skel/’ and, only that:
# l -R /etc/skel/
/etc/skel/:
insgesamt 64
drwxr-xr-x 7 root root 4096 22. Nov 16:57 ./
drwxr-xr-x 137 root root 12288 29. Nov 11:39 ../
-rw------- 1 root root 0 18. Mai 1996 .bash_history
-rw-r--r-- 1 root root 1177 7. Jul 17:10 .bashrc
drwxr-xr-x 2 root root 4096 10. Mai 2017 bin/
drwx------ 2 root root 4096 10. Mai 2017 .config/
-rw-r--r-- 1 root root 1637 11. Sep 2014 .emacs
drwxr-xr-x 2 root root 4096 10. Mai 2017 .fonts/
-rw-r--r-- 1 root root 305 10. Mai 2017 .i18n
-rw-r--r-- 1 root root 861 11. Sep 2014 .inputrc
drwx------ 2 root root 4096 10. Mai 2017 .local/
-rw-r--r-- 1 root root 1028 7. Jul 17:10 .profile
drwxr-xr-x 2 root root 4096 22. Nov 16:53 public_html/
-rw-r--r-- 1 root root 1952 10. Mai 2017 .xim.template
-rwxr-xr-x 1 root root 1112 10. Mai 2017 .xinitrc.template*
/etc/skel/bin:
insgesamt 8
drwxr-xr-x 2 root root 4096 10. Mai 2017 ./
drwxr-xr-x 7 root root 4096 22. Nov 16:57 ../
/etc/skel/.config:
insgesamt 8
drwx------ 2 root root 4096 10. Mai 2017 ./
drwxr-xr-x 7 root root 4096 22. Nov 16:57 ../
/etc/skel/.fonts:
insgesamt 8
drwxr-xr-x 2 root root 4096 10. Mai 2017 ./
drwxr-xr-x 7 root root 4096 22. Nov 16:57 ../
/etc/skel/.local:
insgesamt 8
drwx------ 2 root root 4096 10. Mai 2017 ./
drwxr-xr-x 7 root root 4096 22. Nov 16:57 ../
/etc/skel/public_html:
insgesamt 12
drwxr-xr-x 2 root root 4096 22. Nov 16:53 ./
drwxr-xr-x 7 root root 4096 22. Nov 16:57 ../
-rw-r--r-- 1 root root 48 14. Nov 2014 .directory
#
[HR][/HR]So, how to repair a user’s broken Kmail2 and Akonadi system (which is why I’ve been absent for the past few days . . . » I broke my personal Leap 42.3 KMail and, I’m still recovering archived e-Mail folders with thousands of e-Mails in them. « 
):
- Setup a completely fresh new user, initialise KWallet » meaning, KWallet has to be setup properly with a wallet named “kdewallet” «.
- Execute a KMail2 “1st start” (IMHO it’s better to not
do this by executing “Kontact”) and set up a single e-Mail account – IMAP or POP3. 1. Compare the contents of the new user’s ~/.config/ directory with the exisiting user’s ~/.config/ directory.
A few things to be closely examined, inspected and checked within the problem user’s ~/.config/ directory are:
- ‘akonadi_maildir_resource_0rc’ and all the other “'akonadi_maildir_resource_*rc” files;
- execute “grep -Ri ‘maildir’ *” to determine which files contain “maildir” symbols – check each file which ‘grep’ finds, especially:
[LIST] - akonadi/agentsrc
- kmail2rc
- specialmailcollectionsrc
[/LIST]
For those folks, like me, who have migrated from KDE2 to KDE3 to KDE4 to KDE Plasma 5 (in it’s latest incarnation), what also needs to be done is, to check carefully for old, “not changed or touched in ages”, configuration files:
- it’s usually safe to delete such configuraiton files.
Another thing to do, is to check the contents of active KMail and Akonadi configuration files against the contents of the same files being used by the “new, fresh” user – you need to execute “akonadictl stop” before editing the historical “no longer needed” entries in the configuration files.
Once all that’s been done, start Kontact (or KMail2) and then exit it – Akonadi is now executing again:
- akonadictl status
- akonadictl fsck
- akoandictl vacuum
Restart Kontact (or KMail2) and, check that, everything is as it should be.
so it turns out that KMail is actually lying to me about the status of akonadi.
As you can see in this screenshot . . . .
Query akonadi after booting and it is reported as not running.
Start Kmail and query again and it is reported as running . . . despite kmail reporting otherwise.
https://paste.opensuse.org/view/raw/52077763
Please note this KDE User Base information with respect to Akonadi: <https://userbase.kde.org/Akonadi#Disabling_the_Akonadi_subsystem>.
Please also note, this ArchLinux Wiki with respect to KMail and Akonadi: <https://wiki.archlinux.org/index.php/KDE#PIM>.
sorry . . . but I’m not exactly sure what the relevant info is in the links provided.
In short, the first link states that akonadi will be started by any application that requires it. Kmail does indeed start akonadi as required, yet reports that akonadi has not been started.
Any suspicious messages when starting Kmail from a terminal window?
Any akonadi - kmail related messages in journalct ?
nothing in journalctl but I’m guessing there might be some info from starting kmail in a terminal window . . .
farcus@linux-aw6a:~> kmail
org.kde.pim.akonadicore: "QLocalSocket::connectToServer: Invalid name" "/home/farcus/.local/share/akonadi/akonadiserver-cmd.socket"
org.kde.pim.akonadicore: "QLocalSocket::connectToServer: Invalid name" "/home/farcus/.local/share/akonadi/akonadiserver-cmd.socket"
Pass a valid window to KWallet::Wallet::openWallet().
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
org.kde.pim.webengineviewer: It's not necessary to check database now
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
akonadi.schemaversiontable OK
akonadi.tagattributetable OK
akonadi.tagremoteidresourcerelationtable OK
akonadi.tagtable OK
akonadi.tagtypetable OK
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
this does not work on a KActionCollection containing actions!
org.kde.pim.akonadicore: Socket error occurred: "QLocalSocket::connectToServer: Invalid name"
org.kde.pim.akonadicore: Socket error occurred: "QLocalSocket::connectToServer: Invalid name"
org.kde.akonadi.ETM: GEN true false false
org.kde.akonadi.ETM: collection: QVector()
org.kde.akonadi.ETM:
Pass a valid window to KWallet::Wallet::openWallet().
Pass a valid window to KWallet::Wallet::openWallet().
org.kde.akonadi.ETM: GEN true false false
org.kde.akonadi.ETM: collection: QVector()
org.kde.akonadi.ETM:
org.kde.akonadi.ETM: GEN true false false
org.kde.akonadi.ETM: collection: QVector()
org.kde.akonadi.ETM:
org.kde.akonadi.ETM: GEN true false false
org.kde.akonadi.ETM: collection: QVector()
org.kde.akonadi.ETM:
org.kde.akonadi.ETM: Subtree: 22 QSet(22, 29, 28, 25, 24, 27, 26, 23)
org.kde.akonadi.ETM: Subtree: 15 QSet(17, 16, 19, 18, 15, 21, 20)
org.kde.akonadi.ETM: Subtree: 4 QSet(9, 8, 10, 5, 4, 7, 6)
org.kde.akonadi.ETM: Subtree: 15 QSet(15, 16, 17, 18, 19, 20, 21)
org.kde.akonadi.ETM: Fetch job took 227 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 22
org.kde.akonadi.ETM: first fetched collection: "Local Folders"
org.kde.akonadi.ETM: Subtree: 4 QSet(10, 4, 5, 6, 7, 8, 9)
org.kde.akonadi.ETM: Subtree: 22 QSet(25, 26, 27, 28, 29, 22, 23, 24)
org.kde.akonadi.ETM: Fetch job took 200 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 22
org.kde.akonadi.ETM: first fetched collection: "Local Folders"
org.kde.akonadi.ETM: collection: QVector()
org.kde.akonadi.ETM: Fetch job took 204 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 8
org.kde.akonadi.ETM: first fetched collection: "Search"
org.kde.akonadi.ETM: collection: QVector()
org.kde.akonadi.ETM: Fetch job took 233 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 8
org.kde.akonadi.ETM: first fetched collection: "Search"
org.kde.akonadi.ETM: Fetch job took 3 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 0
org.kde.akonadi.ETM: Fetch job took 2 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 0
org.kde.akonadi.ETM: Subtree: 15 QSet(19, 16, 17, 15, 20, 21, 18)
org.kde.akonadi.ETM: collection: "INBOX"
org.kde.akonadi.ETM: Subtree: 22 QSet(28, 29, 26, 27, 24, 25, 22, 23)
org.kde.akonadi.ETM: Subtree: 4 QSet(10, 8, 9, 6, 7, 4, 5)
org.kde.akonadi.ETM: Fetch job took 164 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 22
org.kde.akonadi.ETM: first fetched collection: "Local Folders"
org.kde.akonadi.ETM: collection: QVector()
org.kde.akonadi.ETM: Fetch job took 234 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 8
org.kde.akonadi.ETM: first fetched collection: "Search"
org.kde.akonadi.ETM: Fetch job took 142 msec
org.kde.akonadi.ETM: was item fetch job: items: 25
org.kde.akonadi.ETM: Fetch job took 202 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 0
2 : "Uncaught TypeError: qt.jQuery is not a function"
2 : "Uncaught TypeError: qt.jQuery is not a function"
[SASL-XOAUTH2] - Requesting authID![SASL-XOAUTH2] - Requesting token
![SASL-XOAUTH2] - filling prompts
![SASL-XOAUTH2] - Requesting authID![SASL-XOAUTH2] - Requesting token
!
There’s something strange with respect to the socket in “/tmp/” which Akonadi needs.
In my “~/.local/share/akonadi/” directory, the only socket there is a link to the “/tmp/” socket – “akonadiserver-cmd.socket” is not present in my “.local/share/akonadi/” directory:
lrwxrwxrwx 1 xxx users 23 20. Aug 2015 socket-XXXX -> /tmp/akonadi-xxx.uKg0Jp/
The only files I have with a name which contains “akonadiserver” are: “~/.config/akonadi/akonadiserverrc” and “~/.local/share/akonadi/akonadiserver.error.old”.
my ~/.local/share/akonadi/ contains a link to /.local/share/akonadi/socket-linux-aw6a/ which contains
akonadiserver-cmd.socket
akonadiserver-ntf.socket
mysql.socket
mysql.pid
I couldn’t tell you why I have them and you don’t. My install is a fairly bog standard 42.3 install.
Mark, could you show us the exact data, i.e. an ls -l of these symlinks ? I also have only one of the symlinks as well.
And, please add the output of
grep -i tmp ~/.config/akonadi/akonadiserverrc