Archive:Http://userbase.kde.org/Akonadi 4.4/Troubleshooting/gl

Introdución

Esta páxina trata de como solucionar os posibles problemas con Akonadi, xa que nas primeiras fases da migración é normal que aparezan algúns. Moita xente reparará en Akonadi por vez primeira na versión 4.4 da compilación de software de KDE, e sentirase algo confusa. No glosario hai unha entrada na que se explica un pouco por riba para que serve Akonadi. Tamén contén ligazóns de interese de cara a ampliar os seus coñecementos sobre o tema. Unha vez se lles poña fin aos inconvenientes inevitables, Akonadi será un potente recurso do que se aproveitarán moitos aplicativos.

Comprensión da estrutura

Por suposto, pode limitarse a usar Kontact para xestionar todos os seus cadernos de enderezos, pero se por exemplo ten un sistema de copias de seguridade, interesaralle saber onde están almacenados os datos, e como se manexan. En tal caso, a páxina sobre Akonadi e os cadernos de enderezos resultaralle de utilidade.

Consellos para a solución de problemas

• Ao informar de problemas co servidor Akonadi inclúa sempre un informe de auto-análise comprensible. Dito informe pode obterse mediante o diálogo de auto-análise, que aparece cada vez que o servidor Akonadi non consigue iniciarse correctamente. Pode atopar dito diálogo no módulo kcmmodule, ao que se accede mediante:

kcmshell4 kcm_akonadi

• Iniciar o servidor Akonadi manualmente dende a liña de ordes pode dar lugar a información adicional de gran utilidade. Para facelo, execute a seguinte orde nunha consola:

akonadictl start

Dun xeito similar, a seguinte orde permite deter de novo o servidor Akonadi:

akonadictl stop

A seguinte orde fornece información de maior utilidade:

akonadictl status

Problemas habituais

Kontact non se inicia nin dá sinais de vida

Se Kontact non se inicia, e non aparece ningunha mensaxe de erro, asegúrese de que Akonadi está executándose. Akonadi debería iniciarse en canto algún aplicativo precise del. Se o seu non fai tal, terá que inicialo antes que Kontact en caso de que migrase xa algún recurso (probablemente KAddressBook). Utilice a icona de Akonadi na bandexa do sistema (que aparece tras executar “akonadi” en KRunner) ou execute as ordes en Konsole para inicialo.

Kontact non se inicia (versión 2)

Polo que se sabe, algunhas actualizacións poden afectar negativamente a Kontact. En tal caso, probe a inicial KMail, KOrganizer ou calquera outro dos seus aplicativos dende KRunner (ou Konsole). É probable que funcionen cada unha de xeito individual mentres descubre cal é o seu problema. Isto afecta principalmente á versión 4.4.0.

Non se atopou o cartafol: "/Local"

Algunhas persoas informaron deste erro, que aparecía en situacións en que Kontact non daba iniciado. Nalgunhas das primeiras versións da póla 4.4 seica había un erro na migración que facía que KMail buscase o correo electrónico local en ~/.local/share/Local, un directorio que non fora configurado. A solución non consiste en intentar corrixilo senón, co KMail e o Kontact pechados, abrir a consola de Akonadi:

• mediante KRunner, Alt+F2, ou
• executando "akonadiconsole" nunha consola.

Then remove the resource that it says is for local mail. You should now find that you can start Kontact or KMail, and that a new resource will be created, pointing to ~/.local/share/local-mail

Hai outros cartafoles novos dentro de ~/.local/share/

Si. Se o seu caderno de enderezos se migrou correctamente, entón crearíase un novo recurso coma ~/.local/share/contacts/

Que son /usr/bin/akonadi_maildir_resource e /usr/bin/akonadi_maildispatcher_agent?

O recurso akonadi_maildir_resource créao automaticamente o axente akonadi_maildispatcher_agent, mentres que este último iníciase sempre xunta o servidor de Akonadi, xa que fornece funcionalidades básicas (coma enviar correos electrónicos) que utilizan todos os aplicativos de correo electrónico (actuais e futuros) baseados en Akonadi. Así que é normal que estean executándose, como usuario pode limitarse a ignoralos. Este recurso akonadi_maildir_resource, xerado de maneira automática, sempre vai apuntar a ~/.local/share/local-mail/, que é a súa conta de "Cartafoles locais" onde se almacenarán os seus cartafoles e correos electrónicos locais.

Nestes momentos, na versión 4.5 da compilación de software de KDE, o correo electrónico aínda non se migrou.

Desactiváronse os axentes da indexación de Nepomuk

Aínda que Kontact funciona, a seguinte mensaxe non deixa de aparecer:

A causa máis habitual é que Nepomuk estea desactivado na Configuración do sistema. Intente activalo na Configuración do sistema en Procura do escritorio -> Configuración básica activando o "escritorio semántico Nepomuk" e premendo en "Aplicar".

Se o problema non se soluciona (ou se a opción xa estaba activada cando se recibiu o erro) e se estivo utilizando versións de proba previas ao lanzamento final da versión 4.4 da compilación de software de KDE, pode que lle afectase un cambio na estrutura da base de datos (por mor dunha actualización do servidor de bases de datos Virtuoso da versión 5 á 6; os lanzamentos estables da versión 4.4 da compilación de software de KDE deben incluír a versión 6 de Virtuoso). As seguintes ordes deberían volver facelo funcionar:

qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit

rm -r ~/.kde/share/apps/nepomuk rm -r ~/.kde4/share/apps/nepomuk

nepomukserver

Note that the above commands will not enable Nepomuk permanently if it isn't already enabled, you have to use System Settings for that.

Para ter un Kontact funcional fai falla un Akonadi funcional, e para este fai falla un Nepomuk funcional. Porén, pode desactivar o indexador de ficheiros Strigi, pois Kontact non o necesita. O indexador de ficheiros Strigi só se utiliza para as procuras no escritorio, o cal non ten nada que ver co Kontact. Simplemente asegúrese de que Nepomuk en si está a funcionar correctamente para Kontact.

En Kontact, Nepomuk utilízase para moitas cousas distintas, dende amosar os vindeiros aniversarios, pasando por xestionar as listas de libres e ocupados, ata amosar a fotografía dun contacto no visor de mensaxes. Se Nepomuk non está funcionando, moitas cousas de Kontact deixarán de funcionar. A mensaxe está para avisarlle da redución da súa funcionalidade. Activar Nepomuk tal e como se describiu previamente soluciona o problema.

Pode comprobar se Nepomuk está funcionando correctamente mediante a seguinte orde:

akonadictl status

Quero usar o meu caderno de enderezos actual e KOrganizer. Podo?

Pode. Ao utilizares a consola de Akonadi para engadir un recurso permítelle escoller como caderno de enderezos estándar. Apunte iso ao seu std.vcf e todo debería funcionar correctamente. A migración non destrúe o seu antigo caderno de enderezos. Pode seguir utilizándoo, se ben perderá todos os beneficios que Akonadi pode ofrecerlle. Tamén pode utilizar ambos os dous cadernos de enderezos, o de Akonadi e mailo orixinal, se así se sente máis seguro.

Non podo ver detalle ningún no meu caderno de enderezos

A día de hoxe descoñécese a causa deste problema, pero a solución é doada. Peche Kontact e inicie KAddressBook por separado. Despois de pechalo poderá volver usalo dende Kontact. Parece que se trata dalgún disparador que non se executa al iniciar o Kontact, e espérase solucionalo en pouco tempo. Seica isto afecta principalmente á versión 4.4.0.

Os meus contactos non aparecer ao utilizar o botón de escoller en KMail

Vaia a Configuración do sistema -> Avanzado (lingüeta) -> Recursos de KDE. Asegúrese de que os seus cadernos de enderezos xestionados por Akonadi estean listados, e engádaos se é preciso. Tamén é unha boa idea aproveitar para configurar o caderno de enderezos principal de Akonadi o predeterminado. Atopará máis información ao respecto aquí.

Como recupero o meu caderno de enderezos de software colaborativo?

Existen dúas solucións: mediante a infraestrutura vella ou mediante a nova.

Mediante a infraestrutura vella: en akonadiconsole, engada un "caderno de enderezos de KDE (tradicional)". O caderno de enderezos de KDE significa que podes configurar o antigo kresources para Akonadi. Na configuración do "caderno de enderezos de KDE (tradicional)", apúntalo a un recurso KResource "IMAP sobre KMail" e en KMail, as opcións de software colaborativo deberían estar activadas. Isto debería funcionar con Kolab, eGroupware, e cadernos de enderezos similares. Deberá marcar as opcións para asegurarse de que escolle o tipo correcto.

Mediante a nova infraestrutura (só se probou con Kolab): no módulo de configuración de Akonadi engada un recurso "servidor de correo electrónico IMAP", e estableza o nome do seu servidor de correo, nome de usuario e contrasinal, e a continuación prema en detectar automaticamente. Para velo execute a seguinte orde:

kcmshell4 kcm_akonadi

Then add a Kolab resource. The next step is to wait for the imap resource to synchronize, which can take quite a long time. The status will appear in the Akonadi configuration module. If nothing happens, try restarting akonadiserver. After some time the Kolab addressbook(s) should appear in KAddressBook.

Os correos electrónicos tardan moito en enviarse

Isto adoita darse cando ademais KMail queda conxelado ata que se envía o correo.

Descubriuse un erro na maneira en que Nepomuk comproba os enderezos, o que pode atrasar moito as cousas. O erro reparouse na versión 4.4.1 da compilación de software de KDE. Para os que sigan nunha versión anterior, existe un remedio:

Peche Kontact, ou KMail e KAddressbook se os está a executar por separado. Desactive Strigi na configuración do sistema. Deteña Nepomuk, borre a base de datos e reinicie nepomukserver. Para iso necesitará executar como usuario as seguintes ordes:

qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit

rm -r ~/.kde/share/apps/nepomuk rm -r ~/.kde4/share/apps/nepomuk

nepomukserver

Isto borrará completamente a súa base de datos, incluíndo calquera etiqueta que engadise. En teoría é posible realizar un borrado máis selectivo da base de datos. Se lle resulta moi importante conservar algúns dos datos, siga as instrucións descritas this page nesta páxina (en inglés).

IMAP Resource always claims to be offline

Even though the system has an internet connection, the IMAP resource refuses to switch to online state.

This bug is caused by a misconfigured NetworkManager installation on your system. Check the output of

qdbus --system org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.state

If it is '4' (Disconnected) but you can access the Internet, then your NetworkManager is indeed configured wrong. If it is '3' (Connected) the problem must be somewhere else. Under Debian this behavior can be caused by interfaces defined in /etc/network/interfaces, which are not controlled by NetworkManager. To fix this, simply remove the entries from /etc/network/interfaces and let NetworkManager handle them.

Algunhas cuestións técnicas=

Nepomuk

Dende a versión 4.4 da compilación de software de KDE, Akonadi precisa de Nepomuk para funcionar correctamente. Akonadi comprobará se está a funcionar, e en caso contrario amosará un diálogo de erro ao iniciarse.

Nepomuk só funciona coa infraestrutura Virtuoso. Pode comprobar se Nepomuk se está a executar coa infraestrutura correcta mediante o diálogo de auto-análise de Akonadi, tal e como se describe a continuación.

Aínda que Nepomuk ten que estar funcionando, pode desactivar a indexación de ficheiros Strigi, que adoita ser a parte da infraestrutura Nepomuk que máis recursos consume.

Apparmor

Algunhas distribucións que utilizan AppArmor téñeno configurado de xeito que impide que Akonadi execute o seu servidor de bases de datos interno. Isto pode dar lugar a unha serie de mensaxes de erro pouco claros, incluído entre outros o seguinte:

unknown error 255 when running akonadictl

"DB error: 'Could not open required defaults file: /home/$username/.local/share/akonadi/mysql.conf"

Pode solucionalo executando a seguinte orde coma superusuario e recargando logo o AppArmor:

aa-complain mysqld

On Kubuntu this is:

sudo aa-complain mysqld
sudo /etc/init.d/apparmor reload

Teña en conta que pode que estea a utilizar o AppArmor mesmo se este non aparece na bandexa do sistema.

Also note that some distributions ship an additional mysqld binary called mysqld-akonadi which has AppArmor set up correctly. If that's the case on your system and you see this problem nevertheless, there are two possible reasons:

• Akonadi still uses mysqld instead of mysqld-akonadi. You can change that in Systemsettings -> Advanced -> Akonadi -> Server configuration.
• AppArmor is not setup correctly for mysqld-akonadi either. Try running the "aa-complain" command noted above with mysqld-akonadi instead of mysqld.

---

You will also experience this problem if you are running an encrypted home directory using encryptfs combined with AppArmor as the Akonadi apparmor profile currently does not account for an ecrypted home (common with Ubuntu Jaunty users). Error messages with include:

• dmesg produces:

ecryptfs_do_create: Failure to create dentry in lower fs; rc = [-13]
ecryptfs_create: Failed to create file inlower filesystem

• Akonadi will list the following errors:

Akonadi server process not registered at D-Bus

The fix is to edit the following file "/etc/apparmor.d/usr.sbin.mysqld-akonadi". Below the line:

@{HOME}/.local/share/akonadi/** rwk,

Add a new line:

@{HOME}/.Private/** rwk,

Restart apparmor and restart akonadi.

Missing Prerequisite

To use Akonadi you need to have the following packages installed (names might differ depending on your distribution):

• The MySQL server (called mysql on openSUSE)
• The Qt4 MySQL plugin (called libqt4-sql-mysql on openSUSE)

If you compile Qt4 yourself, make sure to tell the configure script to build in MySQL support by passing it the following option:

-plugin-sql-mysql

If "configure" cannot locate the necessary MySQL client code (i.e, says "MySQL support cannot be enabled due to functionality tests") then ensure that the corresponding package is installed (typically called [lib]mysql[client]-dev[el]). Also, depending on the install location of the MySQL headers, additional parameters to "configure" might be needed (eg. "-I /usr/include/mysql" on OpenSuse).

If you get the Qt4 direct from Nokia, such as a download of qt-sdk-linux-x86_64-opensource-2009.05.bin, you will ( by the command "akonadictl start") get an error at Test 1:

Database driver not found.

Details: The QtSQL driver 'QMYSQL' is required by your current Akonadi server configuration. The following drivers are installed: QSQLITE.

Make sure the required driver is installed.

The driver you need is libqsqlmysql.so

Unfortunately this driver is not part of the distribution (until january 2010). You need to compile the source. Download the following file:

qt-everywhere-opensource-src-4.6.0.tar.bz

Then configure and make as above. But the make install doesn't copy the driver. So you have to copy it by yourself:

cp <qt-src-dir>/qt-everywhere-opensource-src-4.6.0/plugins/sqldrivers/libqsqlmysql.so /usr/local/bin/sqldrivers/

But the Revision 4.6.1, such as qt-sdk-linux-x86_64-opensource-2010.xx.bin has the driver you needed.

Environment Setup

The Akonadi server searches for Akonadi agents and resources in the paths defined in the XDG_DATA_DIRS environment variable. If Akonadi complains about not finding agents or resources, check if this variable is set correctly. Also keep in mind that even if set in a current console session, it might not have been set when starting the server. Starting the server manually in the current console session excludes this cause.

mysqld: unknown variable 'innodb_file_per_table=1'

If the MySQL server log contains the following error, then your MySQL server was built without the InnoDB support which is required by Akonadi or InnoDB needs to be loaded in your mysql.conf file:

[ERROR] /usr/libexec/mysqld: unknown variable 'innodb_file_per_table=1'

[ERROR] Aborting

Try adding:

#sql_mode=strict_trans_tables <- Add underneath this line

1. plugins

plugin_dir=usr/lib/mysql/plugin < - This may be a different path

plugin-load=ha_innodb.so

Table 'mysql. servers' doesn't exist

If MySQL server log contains the following error, then, most probably, you don't have your MySQL configuration file in place:

[ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist

[ERROR] Cannot open mysql.db [ERROR] Cannot open mysql.user

[ERROR] Cannot open mysql.event

Copy it from /usr/share/config/akonadi/mysql-global.conf into ~/.config/akonadi/mysql-local.conf. (For debian and openSuSE users the file is located in /etc/akonadi/mysql-global.conf). Then open it and uncomment the line sql_mode=strict_trans_tables. After that, you may get the following errors:

[ERROR] Plugin 'InnoDB' init function returned error.

[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. [ERROR] Unknown/unsupported table type: innodb

[ERROR] Aborting

If so, then in the same file find the line that starts just like the one above (which you have uncommented), but has additional parameters, separated by commas (something like sql_mode=strict_trans_tables,strict_all_tables, ...etc). Comment the shorter sql_mode=... line and uncomment the longer one.

On openSUSE 11.2 running the following command will fix this problem:

mysql_install_db --datadir=$HOME/.local/share/akonadi/db_data/

Kubuntu 10.04 (Lucid Lynx) Upgrade

This is a summary of other entries here for those upgrading from Kubuntu 9.10 to 10.04 who may have been using a personal package archive (PPA) for KDE 4.3 for bug fixes.

Install missing prerequisites. Remove previous akonadi cache. Start the akonadi service. Install the database. Upgrade the database. Stop and restart the akonadi service.

sudo apt-get install virtuoso-server mysql-server-5.1

rm -r $HOME/.local/share/akonadi akonadictl start mysql_install_db --datadir=$HOME/.local/share/akonadi/db_data/ mysql_upgrade --socket=$HOME/.local/share/akonadi/db_misc/mysql.socket akonadictl stop

akonadictl start

The mysql_install_db command above will report something like the following, which you can safely ignore:

Installing MySQL system tables...

100501 18:04:30 [Warning] Can't create test file

/home/[userid]/.local/share/akonadi/db_data/[hostname].lower-test

Reference: forum.kde.org Akonadi 1.2.1 - some issues

KAddressBook upgrade

In addition to the Kubuntu 10.4 remedy above, problems trying to add a Vcard directory may require the following command while Akonadi is not running:

rm -rf $HOME/.config/akonadi

Can't initialize character set latin1

If you get the following error when starting Akonadi, then you are probably using a MySQL server which has a version > 5.1.42:

Character set 'latin1' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file

Nepomuk QueryServer interface not available! Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) DataStore::unhideAllPimItems() Character set 'latin1' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file Database error: Cannot open database. Last driver error: "QMYSQL: Unable to connect" Last database error: "Can't initialize character set latin1 (path: /usr/share/mysql/charsets/)" Database error: Cannot open database. Last driver error: "QMYSQL: Unable to connect" Last database error: "Can't initialize character set latin1 (path:

/usr/share/mysql/charsets/)"

There is a known regression in MySQL 5.1.43 and 5.1.44 which prevents MySQL from starting.

See the bug report for more details.

Restarting after a previous error

If you had problems starting Akonadi and fixed those (such as a missing package or the Apparmor problem) make sure that the Akonadi server is completely shut down before trying to start it again, by calling on the command line:

akonadictl stop

You can confirm that it was indeed shut down completely by running:

akonadictl status

Under some circumstances the Akonadi server can be stuck in a partially running state after a failure which will prevent the next attempt to start it to fail as well. Please file a bug report if you run into this problem including the self-test report of the initial problem.

The so-called "Gentoo-Assert"

That's an especially nasty problem that so far only affects users of source-based distributions, most prominently Gentoo. It is named after MySQL assertions like the following example and is most likely caused by a MySQL protocol mismatch between the MySQL server and the client library or the Qt MySQL driver.

akonadiserver: libmysql.c:4301: setup_one_fetch_function: Assertion

`param->buffer_length != 0' failed.

It is extremely hard to diagnose as the assertion mentioned above is only triggered sometimes. Instead you'll get a wide range of weird symptoms:

• ASAP protocol logs show successful creation of objects which are supposedly no longer available when the next commands access them again.
• SQL protocol logs show INSERT or UPDATE commands with values that mismatch the corresponding column types and nevertheless succeed.
• SQL protocol logs showing large apparently random record ids which are nevertheless considered valid.

References:

• http://forum.kde.org/viewtopic.php?f=20&t=61738
• http://bugs.gentoo.org/show_bug.cgi?id=267513
• https://bugs.kde.org/202623 (contains a possible solution)
• http://bbs.archlinux.org/viewtopic.php?id=78358

Possible solution: Rebuild the Qt MySQL driver after upgrading MySQL (which most likely caused this problem in the first place).