View source for Archive:Http://userbase.kde.org/Akonadi 4.4/Troubleshooting/it

<languages />
==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 '''[[Glossary/it#Akonadi|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_and_AddressBook/it|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:
{{input|1=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:
{{input|1=akonadictl start}}
Similarly, with this command the Akonadi server can be stopped again:
{{input|1=akonadictl stop}}
This command gives more useful information:
{{input|1=akonadictl status}}
==Problemi comuni==

===Kontact non si avvia e non mi dice niente===<!--doppia negazione-->

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"=== <!--T:13-->

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.

===Ci sono altre nuove cartelle in ~/.local/share/===

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:

[[image:NepomukError.png|418px|center]]

Il motivo più comune per questo avviso è che '''Nepomuk''' è semplicemente disabilitato in '''System Settings'''. Prova ad abilitarlo in '''System Settings''' sotto <menuchoice>Avanzate -> Ricerca desktop -> Impostazioni di base</menuchoice> 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:

<!--T:97-->
:::{{input|1=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:
{{input|1=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 <menuchoice>System Settings -> scheda Avanzate -> Risorse di KDE</menuchoice>. 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 [[KAddressBook_4.4/it#Configurazione_della_tua_nuova_rubrica_(AddressBook)|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:
{{input|1=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):

<!--T:42-->
:::{{input|1=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 [http://techbase.kde.org/Development/Tutorials/Metadata/Nepomuk/TipsAndTricks#Remove_all_Strigi-indexed_data questa pagina]

== 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:
:::{{output|1=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:
{{input|1=aa-complain mysqld}}

Su ''Kubuntu'' fai così:
 
{{input|1=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 <menuchoice>Systemsettings -> Avanzate -> Akonadi -> Configurazione del server</menuchoice>.
* '''AppArmor''' non è impostato correttamente neanche per '''mysqld-akonadi'''. Prova ad eseguire il comando "aa-complain" sopracitato con '''mysqld-akonadi''' invece di '''mysqld'''. 

<!--T:54-->
---

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:
{{output|1=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:
{{output|1=Akonadi server process not registered at D-Bus}}

La soluzione è modificare il seguente file "/etc/apparmor.d/usr.sbin.mysqld-akonadi".
Sotto la riga:
{{output|1=@{HOME}/.local/share/akonadi/** rwk,}}
aggiungine una nuova:
{{input|1=@{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:
{{input|1=-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 <code>qt-sdk-linux-x86_64-opensource-2009.05.bin</code>, otterrai (dal comando "akonadictl start") un errore al Test 1:

<!--T:99-->
:::{{output|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:
{{input|1=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:
{{input|1=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' === <!--T:69-->

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:
:::{{output|1=[ERROR] /usr/libexec/mysqld: unknown variable 'innodb_file_per_table=1'
[ERROR] Aborting}}

Try adding:

<!--T:100-->
:::{{input|1=#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===

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

<!--T:102-->
:::{{output|1=[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:

<!--T:104-->
:::{{output|1=[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:

      <!--T:106-->
{{input|1=mysql_install_db --datadir=$HOME/.local/share/akonadi/db_data/}}

=== Kubuntu 10.4 Upgrade ===

This is a summary of other entries here for those upgrading from ''Kubuntu 9.10'' to 10.4 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.
:::{{input|1=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:

<!--T:108-->
:::{{output|1=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:
[http://forum.kde.org/viewtopic.php?f=20&t=79717 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:
:::{{input|1=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:

<!--T:84-->
:::{{output|1=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 [http://bugs.kde.org/226960 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:
{{input|1=akonadictl stop}}
You can confirm that it was indeed shut down completely by running:
{{input|1=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.

<!--T:92-->
:::{{output|1=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).

[[Category:Sistema_(it)]]