Archive:Http://userbase.kde.org/Akonadi 4.4/Troubleshooting/es
Introducción
Esta página se centra principalmente en la solución de problemas de Akonadi, puesto que hay fallos inevitables en las primeras etapas de la migración. Para mucha gente los primeros signos de actividad de Akonadi llegarán con KDE SC 4.4, y muchos se sentirán confusos. Para ver una breve descripción del propósito de Akonadi, visita esta entrada del Glosario. También encontrarás enlaces útiles a otras lecturas Una vez que los inevitables problemas iniciales se acaben, Akonadi proporcionará todo su poder a muchas aplicaciones.
Comprender la estructura
Por supuesto, puedes simplemente usar Kontact para gestionar tu libreta de direcciones, pero si utilizas algún sistema de copias de seguridad, por ejemplo, querrás saber donde están tus datos, y como se manipulan. La página Akonadi y AddressBook te ayudará.
Consejos para la resolución de problemas
- Cuando informes sobre problemas con el servidor Akonadi, incluye siempre el exhaustivo informe de autoevaluación. Este informe puedes obtenerlo del diálogo de autoevaluación que se muestra siempre que el servidor Akonadi no ha sido capaz de iniciarse con éxito. Puedes encontrar el diálogo de autoevaluación en kcmmodule que es accesible vía:
kcmshell4 kcm_akonadi
- Iniciar el servidor Akonadi manualmente desde una terminal puede proporcionar información adicional. Puedes hacer esto ejecutando el siguiente comando en una consola:
akonadictl start
De forma similar, con la siguiente orden puedes volver a parar el servidor Akonadi de nuevo:
akonadictl stop
Este comando te dará más información útil:
akonadictl status
Problemas comunes
Kontact no se inicia, y no muestra ningún mensaje
Si Kontact no se inicia y no muestra ningún mensaje de error, comprueba que Akonadi esté ejecutándose. Akonadi debería arrancar cuando es demandado. Si no es tu caso, deberás iniciarlo antes de arrancar Kontact si tienes algún recurso migrado (posiblemente KAddressBook). Utiliza el icono Akonadi en la bandeja del sistema (para que aparezca, teclea "akonadi" en KRunner) o teclea la orden en konsole para iniciarlo.
Kontact no se inicia - versión II
Se sabe que Kontact es afectado después de una actualización. Si esto ocurre, intenta ejecutar KMail, KOrganizer o cualquier otra aplicación desde KRunner (o Konsole). Hay muchas posibilidades de que funcionen como aplicaciones independientes mientras buscas que es lo que ha ido mal. Esto afecta principalmente a la versión 4.4.0.
Folder not found: "/Local"
Algunas personas han informado de este error, cuando Kontact no se inicia. En las primeras versiones de la serie 4.4 parece ser un fallo en la migración que indica a KMail que busque el correo local en ~/.local/share/Local, un directorio que no ha sido configurado. La solución para esto es, con KMail/Kontact cerrados, abrir la Consola de Akonadi:
- Usa krunner, Alt-F2, o
- "akonadiconsole" konsole
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
Si. Si tu libreta de direcciones se ha migrado correctamente, se habrá creado un nuevo recurso en ~/.local/share/contacts/
¿Qué son /usr/bin/akonadi_maildir_resource y /usr/bin/akonadi_maildispatcher_agent?
El akonadi_maildir_resource es creado automáticamente por el akonadi_maildispatcher_agent, mientras que el segundo siempre se inicia junto con el Servidor Akonadi puesto que proporciona funcionalidad básica (por ejemplo, enviar un correo electrónico) que es usada por las aplicaciones de correo electrónico que están (o estarán) basadas en Akonadi. Por lo tanto, si eres un usuario normal, puedes ignorar que estas dos aplicaciones estén en ejecución. El recurso autogenerado akonadi_maildir_resource, siempre apuntará a ~/.local/share/local-mail/ que es donde se guardarán tus carpetas y correos locales.
En este momento, con KDE SC 4.4, el correo electrónico no está siendo migrado.
Los agentes de indexado de Nepomuk han sido desactivados
Kontact funciona pero siempre ves el siguiente aviso:
La razón más común para ver este aviso es que Nepomuk simplemente está desactivado en System Settings. Por favor, prueba a activarlo en System Settings: marcando "Escritorio semántico Nepomuk" y haciendo clic en "Aplicar".
Si esto no te funciona (o si la opción ya estaba marcada cuando recibías el mensaje de error) y si has estado utilizando versiones preliminares de KDE SC 4.4, puedes estar afectado por un cambio en el diseño de la base de datos (debido a una actualización del servidor de bases de datos Virtuoso desde la versión 5 a la versión 6; se espera que las versiones de producción de KDE SC 4.4 trabajen con la versión 6 de Virtuoso). Las siguientes órdenes deberían hacer que volviera a funcionar:
qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
rm -r ~/.kde/share/apps/nepomuk rm -r ~/.kde4/share/apps/nepomuk
nepomukserver
Ten en cuenta que los comandos anteriores no activarán Nepomuk de forma permanente si no lo estaba previamente. Tienes que usar System Settings para eso.
Para que Akonadi, y por tanto Kontact, funcione es necesario que Nepomuk esté en ejecución. Sin embargo, puedes desactivar el indexador de archivos Strigi, el cual no es necesitado por Kontact. El indexador de archivos Strigi es utilizado para las búsquedas de escritorio únicamente, por lo que no guarda relación con Kontact. Simplemente debes asegurarte de que Nepomuk esté en ejecución correctamente para que funcione Kontact.
En Kontact, Nepomuk es utilizado para muchas cosas diferentes, desde mostrar los próximos cumpleaños, pasando por la gestión de listas libre/ocupado, hasta mostrar la foto de un contacto en el visor de mensajes. Si Nepomuk no está en ejecución, varias cosas en Kontact dejarán de funcionar. El aviso está ahí para alertarte sobre la funcionalidad reducida. La activación de Nepomuk como se describe más arriba soluciona el problema.
Puedes comprobar si Nepomuk está funcionando correctamente tecleando:
akonadictl status
Quiero utilizar mi libreta de direcciones y organizador actuales. ¿Puedo?
Si. Cuando utilices la Consola de Akonadi para añadir recursos, te permite elegirlo como Libreta de direcciones estándar - teniendo en cuenta que tu std.vcf debería funcionar bien. La migración no destruye tu libreta de direcciones antigua. Puedes continuar usándola, aunque perderás los beneficios que trae Akonadi. Como alternativa, puedes tener ambas, una libreta de direcciones de Akonadi y la tuya original, durante un tiempo, si te sientes más seguro de esa manera.
No puedo ver ningún detalle en mi libreta de direcciones
En este momento, la causa de esto no está identificada, pero la solución es sencilla. Cierra Kontact, e inicia KAddressBook como una aplicación independiente. Después de que la cierres podrás usarla desde Kontact. Parece que hay algo que no está siendo iniciado cuando se lanza Kontact, y esperamos identificarlo y repararlo pronto. Afecta principalmente a la versión 4.4.0.
Mis contactos no se muestran cuando uso el botón Seleccionar en KMail
Comprueba . Asegúrate de que la libreta de direcciones controlada por Akonadi está listada ahí - añádela si es necesario. Al mismo tiempo, es una buena idea hacer que tu libreta de direcciones principal de Akonadi, normalmente llamada "Contactos personales", sea la utilizada por defecto. Puedes encontrar más detalles sobre esto en aquí.
¿Cómo recupero mi libreta de direcciones Groupware?
Hay dos soluciones: utilizando la infraestructura antigua o la nueva.
Old framework: In akonadiconsole, add a "KDE Address Book (traditional)". The KDE Address Book means you can set up old kresources for Akonadi. In the configuration of "KDE Address Book (traditional)", you point it to an "IMAP over KMail" KResource and in KMail, the groupware options should be enabled. This should work for Kolab, eGroupware and similar addressbooks - you will need to check the options to make sure that the correct type is selected.
New framework (only tested with Kolab): In the Akonadi configuration module add an "IMAP E-Mail Server" resource, and set up your mail server name, username and password, then click Auto-Detect. Run this command to see it:
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.
Experimentas importantes demoras al enviar correos electrónicos
Esto es acompañado por la congelación de KMail hasta que el correo es enviado.
Se ha encontrado un fallo en la forma en que Nepomuk comprueba las direcciones, que puede causar grandes retrasos. Está reparado en SC 4.4.1. Si no puedes obtener la versión 4.4.1 todavía, aquí tienes una solución temporal:
Cierra Kontact, o KMail y KAddressbook si estás ejecutando las aplicaciones por separado. Desactiva Strigi en SystemSettings. Detén Nepomuk, elimina la base de datos y reinicia nepomukserver. Las órdenes que necesitas son (como usuario):
qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
rm -r ~/.kde/share/apps/nepomuk rm -r ~/.kde4/share/apps/nepomuk
nepomukserver
Esto, por supuesto, eliminará toda tu base de datos, incluyendo las etiquetas que hayas añadido. En teoría, entiendo que es posible hacer una limpieza más selectiva de la base de datos. Si estos es importante para ti puedes encontrar las instrucciones en esta página
Algunas cuestiones técnicas
Nepomuk
Desde KDE 4.4, es necesario que Nepomuk esté funcionando para que Akonadi trabaje correctamente. Akonadi comprobará esto y mostrará un diálogo de error al inicio si no es el caso.
Nepomuk solo funciona con el motor Virtuoso. Puedes comprobar si Nepomuk se ejecuta con el sistema correcto utilizando el diálogo de auto-prueba de Akonadi, como se describió más arriba.
Aunque Nepomuk es un requisito necesario, puedes desactivar el indexador de archivos Strigi, que es la parte que más recursos consume de la infraestructura de Nepomuk.
Apparmor
Algunas distribuciones que utilizan Apparmor lo han configurado de forma que previene que Akonadi utilice su servidor de bases de datos interno. Esto puede resultar en una gran variedad de mensajes de error, incluyendo los siguientes (entre otros):
unknown error 255 when running akonadictl
"DB error: 'Could not open required defaults file: /home/$username/.local/share/akonadi/mysql.conf"
Puedes solucionar esto ejecutando la siguiente orden con privilegios de administrador y reiniciando apparmor posteriormente.
aa-complain mysqld
En Kubuntu sería:
sudo aa-complain mysqld sudo /etc/init.d/apparmor reload
Ten en cuenta que puedes estar utilizando Apparmor incluso si no se muestra en tu lista de procesos.
Ten en cuenta también que algunas distribuciones proporcionan un binario adicional de mysqld llamado mysqld-akonadi que tiene AppArmor configurado correctamente. Si este es el caso de tu sistema y ves este problema, hay dos posibles razones:
- Akonadi todavía utiliza mysqld en lugar de mysqld-akonadi. Puedes cambiarlo en .
- AppArmor tampoco está configurado correctamente para mysqld-akonadi. Intenta ejecutar la orden "aa-complain" mostrada arriba con mysqld-akonadi en lugar de mysqld.
---
También experimentarás este problema si tienes un directorio home encriptado utilizando encryptfs combinado con AppArmor puesto que el perfil Akonadi apparmor actualmente no puede utilizar una cuenta en una Home encriptada (común en los usuarios de Ubuntu Jaunty). Algunos mensajes de error son:
- la salida de dmesg es:
ecryptfs_do_create: Failure to create dentry in lower fs; rc = [-13] ecryptfs_create: Failed to create file inlower filesystem
- Akonadi mostrará los siguientes errores:
Akonadi server process not registered at D-Bus
La solución pasa por editar el archivo "/etc/apparmor.d/usr.sbin.mysqld-akonadi". Bajo la línea:
@{HOME}/.local/share/akonadi/** rwk,
Añade una nueva línea:
@{HOME}/.Private/** rwk,
Reinicia apparmor y reinicia akonadi.
Prerrequisitos ausentes
Para usar Akonadi necesitas tener instalados los siguientes paquetes (los nombres pueden variar dependiendo de la distribución):
- El servidor MySQL (llamado mysql en openSUSE)
- El plugin Qt4 MySQL (llamado libqt4-sql-mysql en openSUSE)
Si compilas Qt4 por ti mismo, asegúrate de decirle al script de configuración que compile con soporte para MySQL pasándole la siguiente opción:
-plugin-sql-mysql
Si "configure" no puede localizar el código del cliente MySQL necesario (por ejemplo, dice que "el soporte de MySQL no puede ser activado debido a los test de funcionalidad") asegúrate de que está instalado el paquete correspondiente (normalmente llamado [lib]mysql[client]-dev[el]). También, dependiendo de donde esté localizada la instalación de las MySQL headers, pueden ser necesarios parámetros adicionales para "configure" (por ejemplo "-I /usr/include/mysql" en OpenSuse).
Si obtienes Qt4 directamente desde Nokia, como por ejemplo con la descarga de qt-sdk-linux-x86_64-opensource-2009.05.bin, obtendrás (con la orden "akonadictl start") un error en el 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.
El driver que necesitas es libqsqlmysql.so
Lamentablemente este driver no es parte de la distribución (hasta enero de 2010). Necesitas compilar las fuentes. Descarga el siguiente archivo:
qt-everywhere-opensource-src-4.6.0.tar.bz
Luego ejecuta configure y make como siempre. Pero la orden make install no copia el driver por lo que tendrás que hacerlo por ti mismo:
cp <qt-src-dir>/qt-everywhere-opensource-src-4.6.0/plugins/sqldrivers/libqsqlmysql.so /usr/local/bin/sqldrivers/
Pero la revisión 4.6.1, como por ejemplo qt-sdk-linux-x86_64-opensource-2010.xx.bin tiene el driver que necesitas.
Configuración del entorno
El servidor Akonadi busca agentes y recursos de Akonadi en las rutas definidas en la variable de entorno XDG_DATA_DIRS . Si Akonadi se queja de que no puede encontrar agentes o recursos, comprueba si esta variable está configurada correctamente. Ten también en cuenta que incluso si la pones en la sesión actual de consola, pueden no haber sido activada cuando se inicia el servidor. Si arrancas el servidor manualmente en la sesión de consola actual se excluye esta causa.
mysqld: unknown variable 'innodb_file_per_table=1'
Si el registro del servidor MySQL contiene el siguiente error, entonces tu servidor MySQL fue construido sin soporte para InnoDB, que es requerido por Akonadi, o InnoDB necesita ser cargado en tu archivo mysql.conf:
[ERROR] /usr/libexec/mysqld: unknown variable 'innodb_file_per_table=1'
[ERROR] Aborting
Prueba a añadir:
#sql_mode=strict_trans_tables <- Add underneath this line
- plugins
plugin_dir=usr/lib/mysql/plugin < - This may be a different path
plugin-load=ha_innodb.so
Table 'mysql. servers' doesn't exist
Si el registro del servidor MySQL contiene el siguiente error entonces, probablemente, no tienes tu archivo de configuración de MySQL en su sitio:
[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
Copia el archivo /usr/share/config/akonadi/mysql-global.conf a ~/.config/akonadi/mysql-local.conf. (Para usuarios de debian y openSuSE el archivo se encuentra en /etc/akonadi/mysql-global.conf). Luego ábrelo y descomenta la línea sql_mode=strict_trans_tables. Después de esto puedes obtener los siguientes errores.
[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. [ERROR] Unknown/unsupported table type: innodb
[ERROR] Aborting
Si es así, entonces en el mismo archivo busca la línea que empieza justo igual que la anterior (la que has descomentado), pero que tiene parámetros adicionales, separados por comas (algo como sql_mode=strict_trans_tables,strict_all_tables, etc). Comenta la línea corta sql_mode=... y descomenta la línea larga.
En openSUSE 11.2 la ejecución de la siguiente orden solucionará este problema:
mysql_install_db --datadir=$HOME/.local/share/akonadi/db_data/
Actualización a Kubuntu 10.4
Esto es un resumen de otras entradas de aquí para aquellos que actualicen desde Kubuntu 9.10 a 10.4 que puedan haber estado usando un personal package archive (PPA) de KDE 4.3 para resolución de fallos.
Instala los prerrequisitos que falten. Elimina el caché anterior de akonadi. Inicia el servicio akonadi . Instala la base de datos. Actualiza la base de datos. Para y reinicia el servicio akonadi.
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
La orden mysql_install_db anterior te informará de algo como lo siguiente, que puedes ignorar con seguridad:
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 are 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 accesses 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).