Archive:Http://userbase.kde.org/Akonadi 4.4/Troubleshooting/pl
Wprowadzenie
Ta strona w dużej mierze dotyczy rozwiązywania problemów z Akonadi, ponieważ na tym etapie jego rozwoju nietrudno napotkać się na błąd. Wielu ludzi po raz pierwszy spotkało się z Akonadi w KDE SC 4.4 i było dla nich nowością. Krótkie wprowadzenie do Akonadi znajduje się na stronie terminy wyrazów. Znajdują się tam także różne użyteczne odnośniki. Docelowo Akonadi będzie wykorzystywane przez wiele aplikacji.
===Struktura=== \
Oczywiście można używać aplikacji Kontact zarządzając książkami adresowymi, ale w przypadku posiadania jakiegoś system kopii zapasowej, warto wiedzieć gdzie znajdują się dane i jak są zarządzane. Strona Akonadi i książka adresowa może okazać się pomocna.
Rozwiązywanie problemów
- Zgłaszając problemy z serwerem Akonadi należy dołączać pełny raport testowy. Można go zapisać korzystając z okna dialogowego, które pojawia się w momencie problemów z uruchomieniem serwera. Moduł konfiguracyjny Akonadi można uruchomić następującym poleceniem:
kcmshell4 kcm_akonadi
- Dodatkowe informacje o stanie serwera Akonadi można uzyskać uruchamiając polecenie:
akonadictl start
Poniższe polecenie zatrzymuje serwer Akonadi:
akonadictl stop
Z kolei to polecenie dostarcza użyteczne informacje:
akonadictl status
Najczęstsze problemy
Kontact nie uruchamia się, nie informując dlaczego
Jeżeli Kontact nie uruchamia się, ale nie pojawia się żadna informacja o błędzie, należy sprawdź czy uruchomione jest Akonadi. Akonadi powinien uruchomić się na żądanie. Jeżeli tak się nie dzieje, należy uruchomić go przed aplikacją Kontact, jeśli są dodane jakieś zasoby (głównie chodzi o KAddressBook). Akonadi można uruchomić klikając ikonę w tacce systemowej uprzednio wpisując polecenie akonadi w KRunner lub konsoli.
Kontact nie uruchamia się - 2. przypadek
Znane są problemy z uruchamianiem aplikacji Kontact po przeprowadzonej aktualizacji. Jeżeli tak się dzieje można spróbować uruchomić z KRunnera lub konsoli KMaila, KOrganizera lub inną aplikację wchodzącą w skład pakietu PIM . Są szanse, że będą one działać jako samodzielne aplikacje. Problemy głównie dotyczą wersji 4.4.0.
Folder not found: "/Local"
Znane są przypadki nie uruchamiającej się aplikacji Kontact. We wczesnych wersjach 4.4 występuje błąd podczas migracji. KMail szuka lokalnej poczty w ~/.local/share/Local, który nie jest jeszcze utworzony. Rozwiązaniem je zamknięcie KMaila/Kontacta i uruchomienie Konsoli Akonadi:*Użyj Krunnera (Alt-F2) lub
- Konsoli i wpisz akonadikonsole
Musisz usunąć zasób służący do przechowywania lokalnej poczty. Teraz można bezpiecznie uruchomić Kontact lub KMail, a now zasób zostanie stworzony, wskazując na ~/.local/share/local-mail
Tak. Jeżeli proces migracji książki adresowej przebiegł pomyślnie, zostanie stworzony nowy zasób jako ~/.local/share/contacts/
Czym są /usr/bin/akonadi_maildir_resource oraz /usr/bin/akonadi_maildispatcher_agent?
akonadi_maildir_resource jest tworzony automatycznie przez akonadi_maildispatcher_agent. Z kolei ten drugi jest uruchamiany wraz z serwerem Akonadi ponieważ udostępnia podstawową funkcjonalność (np. wysyłanie e-maili) wykorzystywaną przez wszystkie klienty pocztowe, które korzystają i będą korzystać z Akonadi. Jako użytkownik możesz je zignorować. Automatycznie wygenerowany akonadi_maildir_resource zawsze będzie wskazywał na ~/.local/share/local-mail który zawiera lokalne foldery i e-maile.
W tym punkcie w KDE SC 4.4 poczta jeszcze nie jest przeniesiona.
Agent indeksowania Nepomuka został wyłączony
Kontact działa, ale pojawia się wiadomość:
Prawdopodobnie Nepomuk jest wyłączony w Ustawieniach Systemowych. Spróbuj włączyć go w zakładce zaznaczając opcję Włącz pulpit semantyczny Nepomuk i klikając Zastosuj.
Jeśli to nie pomoże (lub jeżeli opcja była już zaznaczona) a wcześniej używana była wersja KDE starsza niż 4.4', może występować błąd związany ze zmianą w bazie danych (z powodu aktualizacji serwera baz danych Virtuoso z wersji 5. do 6.; KDE SC 4.4 używa Virtuoso w wersji 6.) Następujące polecenie powinno pomóc:
qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
rm -r ~/.kde/share/apps/nepomuk rm -r ~/.kde4/share/apps/nepomuk
nepomukserver
Powyższe polecenia nie aktywują Nepomuka na stałe - trzeba użyć w tym celu Ustawień systemowych.
Kontact wymaga działającego Akonadi, a ten Nepomuka. Można jednak wyłączyć moduł indeksowania Strigi, który nie jest wymagany przez Kontact.
W aplikacji Kontact, Nepomuk jest używany do wielu czynności: od wyświetlenia nadchodzących urodzin, przez zarządzanie listami wolny/zajęty do pokazywania zdjęcia kontaktu w podglądzie wiadomości. Jeżeli Nepomuk nie jest uruchomiony, niektóre funkcje programu Kontact nie będą działać. Ostrzegamy zatem przed ograniczoną funkcjonalnością. Aktywowanie Nepomuka w sposób pokazany wyżej pozwala uniknąć tych problemów.
W celu sprawdzenia poprawności działania Nepomuka należy wpisać:
akonadictl status
Chcę używać mojej obecnej książki adresowej i organizera - mogę?
Tak. Dodając nowy zasób w Konsoli Akonadi można wybrać Standardową książkę adresową - wskazując na plik std.vcf. Migracja nie uszkodzi starej książki. Można jej w dalszym ciągu używać, jednak nie odnosząc korzyści jakie niesie ze sobą Akonadi. Warto dodać, że można korzystać zarówno z książki adresowej Akonadi i standardowej.
Nie widzę żadnych szczegółów w książce adresowej
W tym momencie przyczyna problemu nie jest znana, ale rozwiązanie proste. Trzeba zamknąć Kontact i uruchomić KAdressBook jako samodzielną aplikację. Następnie zamknąć ją i już można używać ją w aplikacji Kontact. Prawdopodobnie coś nie jest uruchamiane podczas wczytywania programu. Mamy nadzieję, że wkrótce się pojawi odpowiednia poprawka. Błąd dotyczy głównie wersji 4.4.0.
Moje kontakty się nie pojawiają kiedy używam przycisku Zaznacz w KMail
Należy wybrać kolejno . Książka adresowa korzystająca z Akonadi powinna tam się znajdować - w przeciwnym razie należy ją dodać. Warto ustawić książkę adresową Akonadi na domyślną. Więcej na ten temat się znajduje na tej stronie.
Jak mogę przywrócić moją książkę adresową do pracy grupowej?
Są dwa rozwiązania: użycie starej lub nowej technologii.
Rozwiązanie pierwsze: po wpisaniu polecenia akonadiconsole, w oknie dialogowym dodać Książkę adresową KDE. Oznacza ona, że można używać starego kresources dla Akonadi. W konfiguracji, która się pojawiała wybrać pozycję Książka adresowa na serwerze IMAP za pośrednictwem KMail. Następnie należy uaktywnić w opcjach klienta KMail pracę grupową. Powinna ona działać dla Kolaba, eGroupware i podobnych książek adresowych - trzeba zaznaczyć odpowiednią opcję.
Rozwiązanie drugie: nowy framework (testowane tylko z Kolabem): w module konfiguracji Akonadi należy dodać zasób Serwer IMAP; wpisać nazwę serwera, nazwę użytkownika i hasło. Następnie kliknąć przycisk Wykryj automatycznie. Poniższe polecenie otwiera okno konfiguracji:
kcmshell4 kcm_akonadi
Teraz trzeba dodać zasób Kolab. W następnym kroku należy poczekać, aż zasób imap dokona synchronizacji, co może zająć trochę czasu. Odpowiedni status pojawi się w module konfiguracyjnym Akonadi. Jeżeli nic się nie stanie, warto spróbować ponownie uruchomić akonadiserwer. Po pewnym czasie książka adresowa Kolaba powinna pojawić się w KAdressBook.
Długi czas oczekiwania podczas wysyłania wiadomości e-mail
Towarzyszy temu zawieszenie się programu KMail do czasu wysłania wiadomości.
Błąd powodował sposób w jaki Nepomuk sprawdza adresy, co mogło wywołać duże opóźnienia. Naprawiono go w KDE SC 4.4.1. Jeżeli w jakiś sposób użytkownik nie może zainstalować wersji 4.4.1, można skorzystać z następującego obejścia problemu:
Zamknąć Kontact lub KMail i KAdressBook jeżeli są uruchomione jako osobne aplikacje; wyłączyć Strigi w Ustawieniach systemowych; zatrzymać Nepomuka, usunąć bazę danych i ponownie uruchomić nepomukserver. Należy uruchomić następujące polecenia (jako użytkownik):
qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
rm -r ~/.kde/share/apps/nepomuk rm -r ~/.kde4/share/apps/nepomuk
nepomukserver
Powyższa operacja usuwa całą bazę danych, jak również tagi, które zostały dodane. Teoretycznie możliwe jest bardziej wybiórcze usuwanie. Jeżeli jest to istotne warto zajrzeć do instrukcji na tej stronie.
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.
Kwestie techniczne
Nepomuk
Począwszy od wersji KDE 4.4 do poprawnego działania Akonadi wymagany jest działający Nepomuk. Akonadi sprawdza stan działania Nepomuka i w przypadku problemów wyświetla okno z raportem o błędzie.
'Nepomuk działa tylko z "końcówką" (ang. back-end) Virtuoso.
Można sprawdzić czy Nepomuk używa poprawnej końcówki w opisanym wyżej oknie dialogowym.
Chociaż wymaga się by Nepomuk był włączony, można wyłączyć indeksowanie plików Strigi, który jest najbardziej wykorzystującą zasoby komputera częścią Nepomuka.
Apparmor
Niektóre dystrybucje używające Apparmor są tak skonfigurowane, że blokują uruchomienie wewnętrznego serwera baz danych Akonadi. \
unknown error 255 when running akonadictl
"DB error: 'Could not open required defaults file: /home/$username/.local/share/akonadi/mysql.conf"
Problem rozwiązuje uruchomienie poniższego polecenia jako użytkownik root, a następnie ponowne uruchomienie apparmor:
aa-complain mysqld
W Kubuntu należy uruchomić:
sudo aa-complain mysqld sudo /etc/init.d/apparmor reload
Apparmor może działać w tle, nie pojawiając się on na liście procesów.
Warto dodać, że niektóre dystrybucje posiadają dodatkowy mysqld nazwany mysqld-akonadi, który dobrze współpracuje z Apparmor. Jeżeli tak jest w przypadku systemu użytkownika, ale pomimo to pojawiają się problemy, przyczyny mogą być dwojakie:
- Akonadi wciąż używa mysqld zamiast mysqld-akonadi. Można to zmienić, wybierając kolejno .
- Apparmor także nie jest poprawnie skonfigurowany dla mysqld-akonadi. Należy uruchomić polecenie aa-complain wymienione wyżej z parametrem mysqld-akonadi.
---
Problem dotyczy także użytkowników posiadających zaszyfrowaną (encryptfs) partcję /home i używających AppArmor ponieważ profil Akonadi apparmor nie bierze pod uwagę zaszyfrowanej partycji /home (popularne rozwiązanie wśród użytkowników Ubuntu Jaunty). Pojawiają się następujące błędy:
- błąd dmesg:
ecryptfs_do_create: Failure to create dentry in lower fs; rc = [-13] ecryptfs_create: Failed to create file inlower filesystem
- Akonadi poinformuje o następującym błędzie:
Akonadi server process not registered at D-Bus
Rozwiązaniem jest edycja pliku /etc/apparmor.d/usr.sbin.mysqld-akonadi. Poniżej linii:
@{HOME}/.local/share/akonadi/** rwk,
Musisz dodać nową linię:
@{HOME}/.Private/** rwk,
Uruchom ponownie apparmor i akonadi.
Brakujące zależności
Akonadi wymaga zainstalowania następujących pakietów (ich nazwy mogą się różnić w zależności od dystrybucji):
- Serwer MySQL (nazwany mysql w OpenSUSE)
- Wtyczka Qt4 do MySQL (nazwana libqt4-sql-mysql w openSUSE)
Jeżeli biblioteka Qt4 była samodzielnie kompilowana, należy upewnić się, że jest w nią wbudowana obsługa MySQL. Potrzebny jest następujący parametr: \
-plugin-sql-mysql
Jeśli configure nie może znaleźć biblioteki MySQL (tzn. informuje, że obsługa MySQL nie może być włączona z powodu testów funkcjonalności), należy sprawdzić czy jest zainstalowany następujący pakiet (zwykle nazwany [lib]mysql[client]-dev[el]). W zależności od miejsca zainstalowania nagłówków MySQL, mogą być potrzebne dodatkowe parametry configure (np. "-I /usr/include/mysql" w OpenSUSE).
Jeśli Qt4 pochodzi bezpośrednio od Nokii, np. plik qt-sdk-linux-x86_64-opensource-2009.05.bin, wywołując polecenie akonadictl start pojawi się błąd:
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.
Potrzebny jest sterownik libqsqlmysql.so
Niestety ten sterownik nie jest częścią dystrybucji (do stycznia 2010 roku). Trzeba go samodzielnie skompilować ze źródeł, najpierw ściągając plik:
qt-everywhere-opensource-src-4.6.0.tar.bz
Należy standardowo użyć configure i make. make install nie kopiuje automatycznie sterownika. Trzeba to zrobić samemu:
cp <qt-src-dir>/qt-everywhere-opensource-src-4.6.0/plugins/sqldrivers/libqsqlmysql.so /usr/local/bin/sqldrivers/
Ale wersja 4.6.1, taka jak qt-sdk-linux-x86_64-opensource-2010.xx.bin, posiada już odpowiedni sterownik.
Konfiguracja środowiska
Serwer Akonadi szuka agentów (procesów) i zasobów Akonadi w ścieżkach zdefiniowanych w zmiennej środowiskowej XDG_DATA_DIRS. Jeżeli informuje on o nie znalezieniu ich, powinno się upewnić czy ścieżka jest poprawnie ustawiona. Ustawiona ścieżka w aktualnej sesji, może nie być ustawiona kiedy uruchamiany jest serwer podczas startu systemu. Uruchomienie serwera ręcznie w aktualnej sesji wyklucza ten przypadek.
mysqld: unknown variable 'innodb_file_per_table=1'
Jeżeli w dzienniku serwera MySQL pojawia się następujący błąd, oznacza to, że serwer MySQL został zainstalowany bez obsługi InnoDB, który jest wymagany przez Akonadi bądź też nie został dodany odpowiedni wpis w pliku mysql.conf:
[ERROR] /usr/libexec/mysqld: unknown variable 'innodb_file_per_table=1'
[ERROR] Aborting
Można spróbować dodać:
#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
Tabela 'mysql.serwers' nie istnieje
W przypadku gdy dziennik serwera MySQL zawiera błąd, oznacza to prawdopodobnie, że plik konfiguracyjny MySQL znajduje się w nieodpowiednim miejscu:
[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
Należy skopiować go z /usr/share/config/akonadi/mysql-global.conf do ~/.config/akonadi/mysql-local.conf. (W Debianie i OpenSUSE plik znajduje się w /etc/akonadi/mysql-global.conf); otworzyć go i skomentuj linię sql_mode=strict_trans_tables. Po tej operacji może pojawić się błąd:
[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. [ERROR] Unknown/unsupported table type: innodb
[ERROR] Aborting
Jeśli tak się stanie, w tym samym pliku należy odnaleźć linię, która zaczyna się jak ta powyższa (właśnie skomentowana), ale ma dodatkowe parametry, oddzielone przecinkami (w stylu: sql_mode=strict_trans_tables,strict_all_tables, ...itd). Należy skomentować krótszą linię sql_mode=... i odkomentować dłuższą.
Poniższe polecenie uruchomione w systemie openSUSE naprawia problem:
mysql_install_db --datadir=$HOME/.local/share/akonadi/db_data/
Aktualizacja do Kubuntu 10.4
Poniższy tekst dotyczy użytkowników, dokonujących aktualizacji systemu Kubuntu 9.10 do wersji 10.4, używających poprawkowego repozytorium (PPA) dla KDE 4.3.
Powinno się wykonać następujące czynności: zainstalować brakujące zależności; usunąć poprzednią pamięć podręczną akonadi; uruchomić usługę akonadi; zainstalować bazę danych i ją aktualizować. Na końcu należy zatrzymać i ponownie uruchom usługę 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
Jeśli powyższe polecenie mysql_install_db poinformuje o błędzie, można je zignorować:
Installing MySQL system tables...
100501 18:04:30 [Warning] Can't create test file
/home/[userid]/.local/share/akonadi/db_data/[hostname].lower-test
Więcej informacji: forum.kde.org Akonadi 1.2.1 - niektóre błędy
Aktualizacja KAddressBook
Jeżeli podczas dodawania katalogu Vcard pojawią się problemy, należy uruchomić poniższe polecenie przy wyłączonym Akonadi:
rm -rf $HOME/.config/akonadi
Błąd podczas inicjacji znaków z zestawu latin1
Jeżeli podczas uruchamiania Akonadi pojawi się poniższa wiadomość o błędzie, prawdopodobnie zainstalowany jest serwer MySQL w wersji większej od 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/)"
To znana regresja w MySQL 5.1.43 i 5.1.44 które blokują uruchomienie się MySQL.
Więcej szczegółów znajduje się na stronie .
Ponowny start Akonadi po naprawie błędu
Jeżeli pojawiły się błędy z uruchomieniem Akonadi ale zostały naprawione, należy wyłączyć serwer Akonadi przed ponownym uruchomieniem. Poniższe polecenie sprawdza jego stan:
akonadictl stop
Następującym poleceniem można sprawdzić czy Akonadi zostało całkowicie zamknięte
akonadictl status
Czasami serwer Akonadi może "częściowo" działać, szczególnie po uprzednim nieudanym uruchomieniu. W razie napotkania na ten rodzaj błędu, zalecane jest wypełnienie raportu o błędzie i dołączenie dziennika Akonadi (dostępnego do zapisania w oknie dialogowym).
Tak zwany przypadek asercji w Gentoo
To szczególnie trudny problem do zdiagnozowania, który dotyczy użytkowników dystrybucji źródłowych, szczególnie Gentoo. Nazwany jest na cześć asercji w MySQL (przykład niżej) i spowodowany jest niedopasowaniem protokołu MySQL pomiędzy serwerem MySQL a biblioteką klienta bądź sterownikiem Qt MySQL.
akonadiserver: libmysql.c:4301: setup_one_fetch_function: Assertion
`param->buffer_length != 0' failed.
Trudno go zdiagnozować ponieważ asercja wymieniona wyżej jest tylko czasami wywoływana. Zamiast tego mogą pojawić się następujące, dziwne symptomy: Dziennik protokołu ASAP informuje o pomyślnym utworzeniu obiektów, które następnie nie są dostępne, kiedy kolejne polecenia próbują uzyskać do nich dostęp. Dziennik protokołu SQL pokazuje polecenia INSERT lub UPDATE, które nie pasują do odpowiednich typów kolumn, ale pomimo tego informuje o pomyślnym ukończeniu operacji. Dziennik protokołu SQL pokazuje najwyraźniej losowe numery rekordów, które są uznane za poprawne.
Więcej informacji:
- http://forum.kde.org/viewtopic.php?f=20&t=61738
- http://bugs.gentoo.org/show_bug.cgi?id=267513
- https://bugs.kde.org/202623 (zawiera możliwe rozwiązanie)
- http://bbs.archlinux.org/viewtopic.php?id=78358
Możliwe rozwiązanie: przebuduj sterownik Qt MySQL po aktualizacji MySQL (który najprawdopodobniej powoduje problem)