Archive:Http://userbase.kde.org/Akonadi 4.4/Troubleshooting/it
Introduzione
Questa pagina riguarda principalmente la risoluzione dei problemi con Akonadi, dal momento che ci sono inevitabili difetti nelle prime fasi di migrazione. Per molte persone i primi segni di vita di Akonadi saranno visibili in KDE SC 4.4 e molti saranno confusi al riguardo. Per una breve descrizione dello scopo di Akonadi, guarda questa voce del glossario. Troverai anche collegamenti utili per ulteriori approfondimenti. Una volta che gli inevitabili problemi iniziali saranno finiti, Akonadi offrirà una potente base utilizzabile da molte applicazioni.
Comprensione della struttura
Puoi, naturalmente, utilizzare semplicemente Kontact per gestire tutti i tuoi contatti della rubrica, ma se disponi di un sistema di backup, per esempio, vorrai sapere dove si trovano i tuoi dati e come sono gestiti. La pagina Akonadi e AddressBook ti aiuterà.
Consigli per la risoluzione dei problemi
- Nella segnalazione dei problemi con il server Akonadi, includere sempre il rapporto integrale dell'autodiagnostica. Questo rapporto può essere ottenuto dalla finestra di dialogo che viene mostrata ogni volta che il server Akonadi non è stato in grado di avviarsi con successo. Puoi trovare questa finestra nel modulo kcm che è accessibile tramite:
kcmshell4 kcm_akonadi
- L'avvio manuale del server Akonadi dalla riga di comando può dare ulteriori informazioni utili. Questo può essere fatto eseguendo i seguenti comandi in una console:
akonadictl start
Similarly, with this command the Akonadi server can be stopped again:
akonadictl stop
This command gives more useful information:
akonadictl status
Problemi comuni
Kontact non si avvia e non mi dice niente
Se Kontact non si avvia e vedi messaggi d'errore, controlla che Akonadi sia in esecuzione. Akonadi dovrebbe avviarsi su richiesta. Se non è così, dovrai avviarlo prima dell'avvio di Kontact se hai una qualsiasi risorsa migrata (più probabilmente KAddressBook). Utilizza l'icona di Akonadi nel vassoio di sistema (ottenibile digitando "akonadi" in KRunner) o digita i comandi in Konsole per avviarlo.
Kontact non si avvia, seconda versione
È noto che Kontact ha avuto problemi dopo un aggiornamento. Se è successo questo, prova ad avviare KMail, KOrganizer o qualsiasi altra applicazione da KRunner (o Konsole). Le possibilità che queste applicazioni funzionino comunque in modo autonomo sono alte, nel frattempo puoi trovare il problema. Questo riguarda principalmente la versione 4.4.0.
Folder not found: "/Local"
Alcune persone hanno segnalato questo errore nel caso in cui Kontact non si avviava. Sembra che in alcune prime versioni della 4.4 ci sia un bug nella migrazione che segnala a KMail di cercare la posta locale in ~/.local/share/Local, una cartella che non è stata impostata. La soluzione per questo problema non è tentare di correggerlo, ma, con KMail/Kontact chiusi, aprire la Console di Akonadi:
- Utilizza KRunner tramite Alt-F2 o
- "akonadiconsole" Konsole
Quindi rimuovere la risorsa relativa alla posta locale. Ora dovresti accorgerti che puoi avviare Kontact o KMail e che è stata creata una nuova risorsa che punta a ~/.local/share/local-mail.
Sì. Se la tua rubrica è stata migrata correttamente, è stata creata una nuova risorsa in ~/.local/share/contacts/.
Cosa sono /usr/bin/akonadi_maildir_resource e /usr/bin/akonadi_maildispatcher_agent?
Akonadi_maildir_resource è creata automaticamente da akonadi_maildispatcher_agent, mentre il secondo è sempre avviato insieme al server Akonadi dato che fornisce le funzionalità di base (per esempio l'invio della posta) che sono utilizzate da tutte le applicazioni per la posta elettronica che sono (e saranno) basate su Akonadi. Quindi è giusto che questi due siano in esecuzione, come utente puoi semplicemente ignorarli. Questa risorsa (akonadi_maildir_resource) autogenerata punterà sempre a ~/.local/share/local-mail/ che corrisponde al tuo account "Cartelle locali" dove le tue cartelle locali e la posta verranno memorizzate.
A questo punto, in KDE SC 4.4, la posta elettronica non è ancora in fase di migrazione.
Gli agenti di indicizzazione Nepomuk sono stati disattivati
Kontact è ora in esecuzione, ma continui a vedere questo avviso:
Il motivo più comune per questo avviso è che Nepomuk è semplicemente disabilitato in System Settings. Prova ad abilitarlo in System Settings sotto selezionando "Nepomuk Semantik Desktop" e facendo clic su "Applica".
Se questo non risolve il problema (o se l'opzione era già selezionata quando hai avuto il problema) e se prima hai utilizzato una versione di sviluppo di KDE SC 4.4, potresti avere problemi a causa del cambiamento all'organizzazione interna del database (dovuto ad un aggiornamento del server database Virtuoso dalla versione 5 alla 6; le versioni definitive di KDE SC 4.4 dovrebbero fornire la versione 6 di Virtuoso). I seguenti comandi dovrebbero farlo funzionare nuovamente:
qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
rm -r ~/.kde/share/apps/nepomuk rm -r ~/.kde4/share/apps/nepomuk
nepomukserver
Nota che i comandi qui sopra non abiliteranno Nepomuk in modo permanente se non è già attivato, devi utilizzare System Settings per far questo.
Per far funzionare Akonadi, e quindi Kontact, è necessario che Nepomuk sia in funzione. Comunque puoi disabilitare l'indicizzatore Strigi che non è necessario per Kontact. L'indicizzatore Strigi è utilizzato solo per funzioni di ricerca desktop che non solo legate a Kontact. Semplicemente assicurati che Nepomuk sia correttamente in esecuzione per Kontact.
In Kontact, Nepomuk è usato per molte cose diverse che vanno dalla visualizzazione dei prossimi compleanni, alla gestione degli elenchi libero/occupato per mostrare una foto del contatto nel visualizzatore dei messaggi. Se Nepomuk non è in esecuzione, diverse cose in Kontact cesseranno di funzionare. L'avviso è lì per avvertirti delle funzionalità ridotte. Abilitare Nepomuk, come descritto sopra, risolve il problema.
Puoi verificare se Nepomuk è correttamente in esecuzione digitando:
akonadictl status
Voglio utilizzare la mia attuale Rubrica e l'Organizzatore personale. Posso?
Sì. Quando utilizzi la console di Akonadi per aggiungere una risorsa, puoi scegliere Rubrica standard, facendola puntare sul tuo std.vcf dovrebbe funzionare bene. La migrazione non distrugge la tua vecchia rubrica. Puoi continuare ad usarla, sebbene perderai tutti i benefici che Akonadi può portare. In alternativa puoi avere sia una rubrica Akonadi che la tua originale, per un po', se ti senti più sicuro così.
Non posso vedere dettagli nella mia rubrica
Al momento la causa di questo non è identificata, ma la cura è semplice. Chiudi Kontact e avvia KAddressBook come applicazione indipendente. Dopo averla chiusa sarai in grado di utilizzarla insieme a Kontact. Sembra che qualcosa non venga attivato quando viene avviato Kontact. Penso che questo problema sarà identificato e risolto al più presto. Sembra coinvolgere principalmente la versione 4.4.0.
I miei contatti non vengono mostrati quando utilizzo il pulsante Seleziona in KMail
Controlla . Assicurati che la/e tua/e rubrica/he controllata/e da Akonadi sia(no) elencata/e, aggiungile se necessario. Nello stesso momento è buona idea fare in modo che la tua rubrica principale di Akonadi, di solito chiamata "Contatti personali", sia impostata come predefinita. Maggiori dettagli al riguardo sono disponibili qui.
Come riavere la mia rubrica Groupware?
Due soluzioni: utilizzando la vecchia infrastruttura o quella nuova.
Vecchia infrastruttura: in akonadiconsole aggiungi un "KDE Address Book (tradizionale)". KDE Address Book significa che puoi impostare una vecchia kresources per utilizzarla con Akonadi. Nella configurazione di "KDE Address Book (tradizionale)", falla puntare su una KResource "IMAP via KMail" e in KMail dovresti abilitare le opzioni groupware. Questo dovrebbe funzionare per Kolab, eGroupware e rubriche simili. Avrai bisogno di controllare le opzioni per essere sicuro che sia selezionato il tipo corretto.
Nuova infrastruttura (testata solo con Kolab): nel modulo di configurazione di Akonadi, aggiungi una risorsa "Server di posta IMAP" e imposta il nome del tuo server di posta elettronica, il nome utente e la password, quindi fai clic su Identifica automaticamente. Esegui questo comando per farlo:
kcmshell4 kcm_akonadi
Poi aggiungi una risorsa Kolab. Il prossimo passo è aspettare che la risorsa imap venga sincronizzata, potrebbe richiedere molto tempo. Lo stato apparirà nel modulo di configurazione di Akonadi. Se non succede niente, prova a riavviare akonadiserver. Dopo un po' la/e rubrica/he Kolab dovrebbero apparire in KAddressBook.
Si verificano lunghi ritardi quando invii messaggi di posta
Questo si accompagna al "congelamento" di KMail fino a quando il messaggio di posta viene effettivamente spedito.
È stato trovato un bug relativo al modo con cui Nepomuk controlla gli indirizzi. Questo può causare enormi ritardi. Sarà risolto nella SC 4.4.1. Se non puoi avere ancora la 4.4.1, c'è questo espediente:
Chiudi Kontact o KMail e KAddressbook se le stai eseguendo come applicazioni indipendenti. Disabilita Strigi in SystemSettings. Ferma Nepomuk, cancella il database e riavvia nepomukserver. I comandi di cui hai bisogno sono (come utente):
qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
rm -r ~/.kde/share/apps/nepomuk rm -r ~/.kde4/share/apps/nepomuk
nepomukserver
Questo, naturalmente, eliminerà tutto il database, incluse tutte le etichette che hai aggiunto. In teoria ho appreso che è possibile fare una pulizia più selettiva del database. Se questo è importante per te, puoi trovare le istruzioni su questa pagina
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.
Alcuni problemi tecnici
Nepomuk
A partire da KDE 4.4, è necessario che Nepomuk sia in esecuzione perché Akonadi possa funzionare correttamente. Akonadi verificherà questo e mostrerà una finestra di errore all'avvio se non è così.
Nepomuk funziona solo con il backend Virtuoso. Puoi controllare se Nepomuk è in esecuzione con il backend corretto utilizzando la finestra di autodiagnostica di Akonadi, come descritto sopra.
Sebbene Nepomuk debba essere necessariamente in esecuzione, puoi ancora disabilitare l'indicizzazione dei file tramite Strigi che di solito è la parte più avida di risorse dell'infrastruttura Nepomuk.
Apparmor
Alcune distribuzioni che utilizzano Apparmor, lo hanno impostato in un modo che impedisce ad Akonadi di eseguire il suo server database interno. Ciò può comportare una serie di messaggi di errore, incluso, ma non limitato al seguente:
unknown error 255 when running akonadictl
"DB error: 'Could not open required defaults file: /home/$username/.local/share/akonadi/mysql.conf"
Puoi risolvere questo problema eseguendo il comando seguente con i privilegi d'amministratore, poi ricarica apparmor:
aa-complain mysqld
Su Kubuntu fai così:
sudo aa-complain mysqld sudo /etc/init.d/apparmor reload
Nota che potresti stare utilizzando Apparmor anche se non compare nell'elenco dei processi.
Nota inoltre che alcune distribuzioni forniscono un binario mysqld addizionale chiamato mysqld-akonadi che è correttamente impostato in AppArmor. Se è così sul tuo sistema e hai comunque questo problema, ci sono due possibili ragioni:
- Akonadi utilizza ancora mysqld invece di mysqld-akonadi. Puoi cambiarlo in .
- AppArmor non è impostato correttamente neanche per mysqld-akonadi. Prova ad eseguire il comando "aa-complain" sopracitato con mysqld-akonadi invece di mysqld.
---
Sperimenterai questo problema anche nel caso in cui tu stia utilizzando una cartella home cifrata tramite encryptfs in aggiunta ad AppArmor. Questo perché il profilo Akonadi apparmor attualmente non tiene conto di una home cifrata (comune per gli utenti di Ubuntu Jaunty). I messaggi d'errore includono:
- dmesg che produce:
ecryptfs_do_create: Failure to create dentry in lower fs; rc = [-13] ecryptfs_create: Failed to create file inlower filesystem
- * Akonadi che elencherà i seguenti errori:
Akonadi server process not registered at D-Bus
La soluzione è modificare il seguente file "/etc/apparmor.d/usr.sbin.mysqld-akonadi". Sotto la riga:
@{HOME}/.local/share/akonadi/** rwk,
aggiungine una nuova:
@{HOME}/.Private/** rwk,
Riavvia apparmor e akonadi.
Prerequisito mancante
Per utilizzare Akonadi hai bisogno di aver installato i seguenti pacchetti (i nomi possono differire a seconda della tua distribuzione):
- MySQL server (chiamato mysql in openSUSE)
- Qt4 MySQL plugin (chiamato libqt4-sql-mysql in openSUSE)
Se sei solito compilare le Qt4 tu stesso, assicurati di segnalare allo script di configurazione di compilare il supporto a MySQL passandogli la seguente opzione:
-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).
Se hai preso le Qt4 direttamente da Nokia, come ad esempio scaricando qt-sdk-linux-x86_64-opensource-2009.05.bin, otterrai (dal comando "akonadictl start") un errore al 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.
Il driver di cui hai bisogno è libqsqlmysql.so
Purtroppo questo driver non è parte della distribuzione (fino a gennaio 2010). Devi compilare il sorgente. Scarica il seguente file:
qt-everywhere-opensource-src-4.6.0.tar.bz
Quindi configure e make come sopra. Ma make install non copia il driver. Devi quindi copiarlo tu stesso:
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.
Impostazione dell'ambiente
Il server Akonadi cerca agenti e risorse Akonadi nei percorsi definiti dalla variabile d'ambiente XDG_DATA_DIRS. Se Akonadi si lamenta riguardo l'impossibilità di trovare agenti o risorse, controlla se questa variabile è impostata correttamente. Inoltre tieni presente che anche se la imposti in una sessione attuale della console, potrebbe non essere impostata adeguatamente quando avvii il server. Avviare manualmente il server nella sessione attuale della console evita questo problema.
mysqld: unknown variable 'innodb_file_per_table=1'
Se il log del server MySQL contiene il seguente errore, allora il tuo server MySQL è stato compilato senza il supporto a InnoDB che è necessario per Akonadi oppure InnoDB necessita di essere caricato nel tuo file mysql.conf:
[ERROR] /usr/libexec/mysqld: unknown variable 'innodb_file_per_table=1'
[ERROR] Aborting
Prova ad aggiungere:
#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
Se il log del server MySQL contiene il seguente errore, allora, molto probabilmente, il tuo file di configurazione di MySQL non è a posto:
[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 ist 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.
In openSUSE 11.2 eseguire il seguente comando risolverà questo problema:
mysql_install_db --datadir=$HOME/.local/share/akonadi/db_data/
Aggiornare a Kubuntu 10.4
Questo è un riassunto di altri punti qui presenti per quelli che stanno aggiornando da Kubuntu 9.10 alla 10.4 e che potrebbero aver utilizzato un personal package archive (PPA) per KDE 4.3 come bug fix.
Installa le dipendenze mancanti. Rimuovi la cache precedente di akonadi. Avvia il servizio akonadi. Installa il database. Aggiorna il database. Ferma e riavvia il servizio 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
Il comando precedente mysql_install_db riporterà qualcosa di simile al seguente, puoi tranquillamente ignorarlo:
Installing MySQL system tables...
100501 18:04:30 [Warning] Can't create test file
/home/[userid]/.local/share/akonadi/db_data/[hostname].lower-test
Riferimento: forum.kde.org Akonadi 1.2.1 - alcuni problemi
Aggiornamento di KAddressBook
Oltre al rimedio precedente per Kubuntu 10.4, i problemi relativi al tentativo di aggiungere una cartella Vcard potrebbero richiedere il comando seguente mentre Akonadi non è in esecuzione:
rm -rf $HOME/.config/akonadi
Impossibile inizializzare il set di caratteri latin1
Se ottieni il seguente errore quando avvii Akonadi, allora probabilmente stai utilizzando un server MySQL con versione > 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/)"
C'è una regressione nota in MySQL 5.1.43 e 5.1.44 che impedisce l'avvio di MySQL.
Vedi la segnalazione del bug per maggiori dettagli.
Riavvio dopo un precedente errore
Se hai avuto problemi ad avviare Akonadi e li hai sistemati (come un pacchetto mancante o il problema con Apparmor), assicurati che il server Akonadi sia completamente disattivato prima di provare a riavviarlo tramite la riga di comando:
akonadictl stop
You can confirm that it was indeed shut down completely by running:
akonadictl status
In alcune circostanze il server Akonadi può rimanere bloccato dopo un errore in uno stato di parziale esecuzione che impedirà il successivo tentativo di riavviarlo con successo. Se hai questo problema, invia un resoconto del bug che includa il risultato del test autodiagnostico del problema iniziale.
Il cosiddetto "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.
Riferimenti:
- 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 possibile soluzione)
- 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).