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.
Carpeta no encontrada: "/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
Luego elimina el recurso que dice que es para correo local. Deberías poder iniciar Kontact o KMail, y se creará un nuevo recurso apuntando a ~/.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.
Sistema antiguo: En akonadiconsole, añade un "KDE Address Book (tradicional)". KDE Address Book significa que puedes configurar kresources antiguos en Akonadi. En la configuración de "KDE Address Book (tradicional)", apúntalo a un KResource del tipo "IMAP sobre KMail" y en KMail, las opciones de groupware deberían estar activadas. Esto debería funcionar con Kolab, eGroupware y libretas de direcciones similares - necesitarás comprobar las opciones para asegurarte de que está seleccionado el tipo correcto.
Sistema nuevo (probado solo con Kolab): en el módulo de configuración de Akonadi añade un recurso del tipo "Servidor de correo IMAP", y configura el nombre de tu servidor de correo, el nombre de usuario y la contraseña, y luego haz clic en Auto-Detectar. Ejecuta esta orden para verlo:
kcmshell4 kcm_akonadi
Luego añade un recurso Kolab. El siguiente paso es esperar para que el recurso imap se sincronice, lo que puede tardar bastante tiempo. El estado aparecerá en el módulo de configuración de Akonadi. Si no sucede nada, prueba a reiniciar akonadiserver. Después de algún tiempo, la(s) libreta(s) de direccion(es) de Kolab deberían aparecer en 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
El recurso IMAP siempre dice estar offline
Aunque el sistema disponga de conexión a Internet, el recurso IMAP se niega a cambiar al estado online.
Este fallo es causado por una instalación de NetworkManager mal configurada en tu sistema. Comprueba la salida de
qdbus --system org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.state
Si es '4' (Desconectado) pero puedes acceder a Internet, entonces NetworkManager está mal configurado. Si es '3' (Conectado) el problema debe estar en algún otro lugar. En Debian este comportamiento puede ser causado por interfaces definidas en /etc/network/interfaces, que no son controladas por NetworkManager. Para solucionarlo, simplemente elimina las entradas de /etc/network/interfaces y deja que NetworkManager las gestione.
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/
Para Archlinux:
mysql_install_db --datadir=$HOME/.local/share/akonadi/db_data/ --basedir=/usr
Actualización a Kubuntu 10.04 (Lucid Lynx)
Esto es un resumen de otras entradas de aquí para aquellos que actualicen desde Kubuntu 9.10 a 10.04 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
Referencia: forum.kde.org Akonadi 1.2.1 - some issues
Actualización de KAddressBook
Además de lo indicado para Kubuntu 10.04 más arriba, los problemas al añadir un directorio Vcard pueden requerir la siguiente orden mientras Akonadi no se esté ejecutando:
rm -rf $HOME/.config/akonadi
No se puede inicializar el conjunto de caracteres latin1
Si obtienes el siguiente error cuando inicias Akonadi, probablemente estés usando un servidor MySQL versión > 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/)"
Hay una regresión conocida en MySQL 5.1.43 y 5.1.44 que impide que MySQL se inicie.
Visita el informe del fallo para obtener más detalles.
Reiniciar después de un error anterior
Si tenías problemas para iniciar Akonadi y los solucionastes (tales como un paquete que falta o el problema de Apparmor) asegúrate de que el servidor Akonadi esté totalmente apagado antes de iniciarlo de nuevo, ejecutando la siguiente orden:
akonadictl stop
Puedes confirmar que efectivamente se ha apagado por completo ejecutando:
akonadictl status
En algunas circunstancias el servidor Akonadi puede quedarse atascado en un estado de ejecución parcial después de un fallo, lo que impide que al siguiente intento de iniciarlo falle también. Por favor, presenta un informe de fallo si te aparece este problema incluyendo el informe de autodiagnostico del problema inicial.
El llamado "Gentoo-Assert"
Este es un problema especialmente grave que hasta ahora solo afecta a usuarios de distribuciones basadas en código fuente, más destacado en Gentoo. Se llama así por las aserciones MySQL como las del siguiente ejemplo y se debe principalmente a un desajuste del protocolo MySQL entre el servidor MySQL y la librería cliente o el driver Qt MySQL.
akonadiserver: libmysql.c:4301: setup_one_fetch_function: Assertion `param->buffer_length != 0' failed.
Es extremadamente de difícil diagnosticar puesto que las aserciones mencionadas arriba solo aparecen a veces. En su lugar obtendrás una amplia gama de extraños síntomas:
- Registros del protocolo ASAP que muestran la creación con éxito de objetos que supuestamente no están disponibles cuando la siguiente orden accede de nuevo.
- Registros del protocolo SQL que muestran órdenes INSERT o UPDATE con valores que no coinciden con los correspondientes tipos de columnas y que sin embargo se hacen con éxito.
- Registros del protocolo SQL que muestran registros de IDs aparentemente aleatorias y que sin embargo se consideran válidas.
Referencias:
- http://forum.kde.org/viewtopic.php?f=20&t=61738
- http://bugs.gentoo.org/show_bug.cgi?id=267513
- https://bugs.kde.org/202623 (contiene una posible solución)
- http://bbs.archlinux.org/viewtopic.php?id=78358
Posible solución: reconstruye el driver Qt MySQL después de actualizar MySQL (que es lo que probablemente causa el problema en primer lugar).