Akonadi - KDE UserBase Wiki
Jump to content
From KDE UserBase Wiki
Other languages:
Bahasa Indonesia
Nederlands
Türkçe
català
dansk
galego
hrvatski
italiano
polski
português
português do Brasil
română
suomi
svenska
čeština
Ελληνικά
русиньскый
русский
українська
አማርኛ
中文（中国大陆）
中文（臺灣）
Introduction
The
Akonadi
framework is responsible for providing applications with a centralized database to store, index and retrieve the user's personal information. This includes the user's emails, contacts, calendars, events, journals, alarms, notes, etc.
Currently, all
KDE PIM applications
with the exception of
Akregator
are using
Akonadi
to access user's PIM data.
Controlling Akonadi
Akonadi
will start automatically in the background when any application using it is started.
To manually start, stop or restart
Akonadi
, you can use the
akonadictl
command from the commandline.
Using this method, you can get additional useful information on the console.
To start the
Akonadi
server,
akonadictl start
To stop the
Akonadi
server,
akonadictl stop
To restart a running
Akonadi
server,
akonadictl restart
To query the status of the
Akonadi
server,
akonadictl status
Disabling the Akonadi subsystem
The
Akonadi
server is automatically started by any
Akonadi
-enabled application. If you don't want Akonadi to be started after login, you have to ensure that no
Akonadi
-enabled application is launched at login or thereafter. Remember to check
Plasma
applets as well — the
Digital Clock
widget in the default panel, for instance uses
Akonadi
to (optionally) display calendar events and this is enabled in its settings by default (see the "Display Events" option) . You must remove any widgets that may start it from your start-up, if you wish Akonadi to start only when you start
KMail
or other applications.
Remember
If you don't want to have
Akonadi
running on your system at all, you can not use any of the
Akonadi
-enabled applications, such as KMail, KOrganizer or KAddressbook. Such applications will not work when
Akonadi
is disabled using the steps below. Also note, that some
Plasma
widgets, such as the
Digital Clock
uses
Akonadi
To ensure that
Akonadi
is not started, check that no applications require it at login. In particular, open the Plasma clock applet preferences, go to
Calendar
and uncheck
Show events
to prevent Plasma from requesting information from
Akonadi
and thus allowing it to start.
Some Definitions
Real data
By
real data
we mean the data, like the contacts or events. These data are stored either on a groupware server or in local files. Where exactly depends on the resource you are using. E.g. the
Personal Contacts
resource stores its data under
$XDG_DATA_HOME/contacts
Cached data
The
cached data
are copies of the real data that are kept in the database for faster access and offline caching. The database also keeps the
meta data
which are management data needed by
Akonadi
to work correctly.
Configuration data
The
configuration data
are the data that configure the
Akonadi
server and the individual resources. The general configuration data for the server can be found under
$XDG_CONFIG_HOME/akonadi
. The configuration data for each indvidual resources are stored under
$XDG_CONFIG_HOME/akonadi_xyz_resourcerc#
xyz
is name of resource and
its instance number).
The
Akonadi
server configuration is a couple of files in
$XDG_CONFIG_HOME/akonadi
. It contains which data sources and helper programs are active and will be started and watched (so they can be restarted on crashes) by one of
Akonadi's
server processes
(akonadi_control)
Each data source handler (called resources) or helper program (called agents) can have its own configuration although some agents or resources don't require configuration. The general rule is that for every entry in
$XDG_CONFIG_HOME/akonadi/agentsrc
there is a corresponding configuration file in
$XDG_CONFIG_HOME
. For example, if the
[Instances]
section in
agentrc
contains an entry for
akonadi_ical_resource_2
, there is also a config file called
akonadi_ical_resource_2rc
in the
$XDG_CONFIG_HOME directory
Depending on the type of data, such config files for resources will have filenames or directory names of where the data is stored. Common locations are KDE's legacy default files, e.g.
$HOME/.kde/share/apps/korganizer/std.ics
. New default locations are files and directories in
$XDG_DATA_HOME
, e.g.
$XDG_DATA_HOME/contacts
Backup
So now we need to decide what to back up. If you want to backup the "real data", then it depends on the resources you have configured... if you use a groupware server, then the backup should be done there. For contacts, the files under
$XDG_DATA_HOME/contacts
will normally be what you need.
To back up the entire
Akonadi
configuration, including which resources are active and their configuration, you can use the
pimdataexporter'
tool. This, however doesn't back up the Akonadi database containing the cached data and, unfortunately, after restoring the configuration (using the
pimdataexporter
again), Akonadi will have to re-fetch all data again into its cache. This can cause configuration that points to actual mail folders or calendars to get broken and accidentally point to another folder.
After restoring configuration and syncing all data, it's vital to manually check all folder configuration, especially in KMail identities and make sure the folders are configured properly.
Frequently Asked Questions
Where is my data now?
Your data are safely stored outside of
Akonadi
control on your disk (e.g. local maildir folder or iCal calendar), or on a remote server (in case of e.g. email over IMAP or events from a CalDAV calendar).
Akonadi
will optionally store a copy of this data in its database to allow applications to quickly retrieve and display them. Any modifications done to data in the
Akonadi
database will be synced to the actual storage. The main advantage of using the database as a cache is that remote PIM data are available even when you are offline, and you can still interact with them (e.g. mark emails as read or move them, create new events, reschedule existing meetings etc.) and all the changes will get synced automatically once you connect to the internet again.
Thus, deleting the
Akonadi
database will not cause any data to be lost (as long as all pending changes are synced).
How to upgrade my PostgreSQL database?
After updating your PostgreSQL server to a new major version, sometimes you will have to convert your Akonadi database for use with this new version. Instructions can be found on
this page
Migration problems
Akonadi's
Glossary entry
has a brief description of Akonadi's purpose, and other useful links.
How do I switch from MySQL/PostgreSQL to SQLite?
Since Akonadi 6
akonadi-db-migrator
is included in akonadi that allows you to switch the database backend. Where for previous versions this involved deleting and recreating the database a migration is now properly supported by akonadi.
The tool needs to be called with the parameter --newengine to chose to which backend it should to:
--newengine
where
For example:
akonadi-db-migrator --newengine sqlite
If Akonadi Reports Broken or Non-operational
Here are some things to check if Akonadi won't start:
Make sure the Qt database drivers are installed
Look in your Qt installation's sqldrivers (run
qmake -query QT_INSTALL_PLUGINS
to find the top-level plugin installation) directory for the necessary driver. For example, if you using the (default) mysql backend, make sure libqsqlmysql.so is installed.
ls `qmake -query QT_INSTALL_PLUGINS`/sqldrivers/
If you are using a distribution provided akonadi in default configuration, please also raise a bug report with missing dependencies to your distribution.
Make sure the driver .so has all necessary dependencies
Run `ldd` (or even better `lddtree`) on the sqldriver plugin runtime library (.so) and look for any missing run time dependencies.
In our libqsqlmysql.so example, we'd run:
ldd `qmake -query QT_INSTALL_PLUGINS`/sqldrivers/libqsqlmysql.so
and look (grep) in the output for "not found" or other suspicious messages
Use your distro's package manager to install all packages needed so that ldd does not report any missing libraries.
If you are using a distribution provided Qt, please raise a bug report with your distribution about this.
Make sure the driver .so file isn't broken in any other way
Run an `ls -l` on the full path of the .so file and make sure it isn't a broken symbolic link or that read-access hasn't been removed or anything else strange with the .so.
Network Connectivity
Make sure Network Manager does not say "limited connectivity". Akonadi is highly dependent on a fully-functional network connection. Before reporting bugs please fix your network connection.
Using out-of-the-box VPN solutions (eg. ExpressVPN) can be problematic if they are started using a web browser app -- you must start your VPN via the Network Manager (at this time).
Apparmor
Some Linux distributions use AppArmor to restrict the database capabilities with per-program profiles.
Run `sudo aa-complain /usr/bin/akonadiserver` and look for a message like "ERROR: Include file /etc/apparmor.d/local/mariadbd_akonadi not found".
To fix, run:
% touch /etc/apparmor.d/local/mysqld_akonadi /etc/apparmor.d/local/mysqld_akonadi
then:
% systemctl reload apparmor.service; aa-complain usr.bin.akonadiserver
Retrieved from "
Category
System
US