Archive:Http://userbase.kde.org/Akonadi 4.4/Troubleshooting/pt-br

Introdução

Esta página evidencia principalmente a solução de problemas com o Akonadi, uma vez que existem falhas inevitáveis ​​nas fases iniciais de migração. Para muitas pessoas, os primeiros sinais de atividade do Akonadi estará no KDE SC 4.4, e muitas irão ficar confusos com ele. Para uma breve descrição do propósito do Akonadi, veja o item neste glossário. Você também vai encontrar links úteis para posterior leitura. Resolvidos os inevitáveis problemas iniciais, o Akonadi demostrará o seu poder para muitos aplicativos.

Entendendo a estrutura

Você pode, é claro, simplesmente usar o Kontact para gerenciar todos os seus livros de endereços, mas se em vez disso você tiver um sistema de backup, por exemplo, você gostará de saber onde seus dados estão e como são trabalhados. A página Akonadi e livro de endereços irá ajudar.

Dicas para solução de problemas

• Ao relatar problemas com o servidor Akonadi, sempre inclua o relatório de teste automático. Este relatório pode ser obtido a partir da janela que aparece sempre que o servidor Akonadi não for capaz de iniciar com êxito. Você pode encontrar o teste automático no diálogo no kcmmodule que é acessível via:

kcmshell4 kcm_akonadi

• Iniciar o servidor Akonadi manualmente pela linha de comando pode fornecer-lhe informações adicionais úteis. Isto pode ser feito executando o seguinte comando no terminal:

akonadictl start

Da mesma forma, com este comando o servidor Akonadi pode ser interrompido novamente:

akonadictl stop

Este comando fornece mais informações úteis:

akonadictl status

Problemas comuns

O Kontact não inicia e nenhuma mensagem é mostrada

Se o Kontact não iniciar e também não apresentar qualquer mensagem de erro, verifique se o Akonadi está em execução. O Akonadi deveria ser iniciado quando fosse demandado. Se não for o seu caso, você terá que iniciá-lo antes do Kontact se já houve a migração de algum recurso (o mais provável é o KAddressBook). Use o ícone da área de notificação do Akonadi (basta digitar "akonadi" no KRunner) ou digite os comandos no konsole para iniciá-lo.

O Kontact não inicia - versão II

Sabe-se que o Kontact é afetado após uma atualização. Se isto ocorrer, tente iniciar o KMail, o KOrganizer ou qualquer outro aplicativo a partir do KRunner ou do Konsole. Há grandes chances de que funcionem como aplicativos independentes enquanto você tenta identificar o problema. Isto afeta principalmente a versão 4.4.0.

Pasta não encontrada: "/Local"

Algumas pessoas relataram esse erro quando o Kontact não inicia. Em algumas versões anteriores à 4.4 parece haver um erro na migração que está informando ao KMail para procurar as mensagens locais em ~/.local/share/Local, uma pasta que não tinha sido criada. A solução para isso é não tentar corrigi-lo, mas com o KMail/ Kontact fechados, abrir o Console do Akonadi:

• Use krunner, Alt-F2, ou
• "akonadiconsole" konsole

Depois remova o recurso que informa ser o correio local. Você pode agora iniciar o Kontact ou o KMail e um novo recurso será criado, direcionando para ~/.local/share/local-mail.

Existem outras pastas novas em ~/.local/share/

Sim. Se o seu livro de endereços foi migrado corretamente, um novo recurso foi criado como ~/.local/share/contacts/

O que são /usr/bin/akonadi_maildir_resource e /usr/bin/akonadi_maildispatcher_agent?

O akonadi_maildir_resource é criado automaticamente pelo akonadi_maildispatcher_agent, enquanto o segundo sempre é iniciado junto com o Servidor Akonadi, já que proporciona as funcionalidades básicas (por exemplo, enviar um e-mail) que são usadas pelos aplicativos de e-mail que são (ou serão) baseados no Akonadi. Portanto, se você for um usuário normal, pode ignorar estes dois aplicativos que estiverem em execução. O recurso gerado automaticamente akonadi_maildir_resource, sempre irá direcionar para ~/.local/share/local-mail/ que é onde serão armazenados os seus e-mails e pastas locais.

Neste momento, com KDE SC 4.4, os e-mails ainda não estão sendo migrados.

Os agentes de indexação do Nepomuk foram desativados

O Kontact está em execução, mas o aviso a seguir é apresentado:

O motivo mais comum para este aviso é que o Nepomuk simplesmente está desativado nas Configurações do Sistema. Tente ativá-lo em Configurações do Sistema: Avançado -> Pesquisa na área de trabalho -> Configurações básicas marcando "Habilitar o ambiente de trabalho semântico do Nepomuk" e clicando em "Aplicar".

Se isto não ajudar (ou se a opção já estava assinalada quando você obteve o erro) e se você já tinha usado previamente versões anteriores do KDE SC 4.4, é possível que seja um problema decorrente de alguma alteração de leiaute do banco de dados (devido a uma atualização da versão 5 para a 6 do servidor de banco de dados Virtuoso; espera-se que as versões de produção do KDE SC 4.4 sejam lançadas com a versão 6 do Virtuoso). Os comandos a seguir devem fazê-lo funcionar novamente:

qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
rm -r ~/.kde/share/apps/nepomuk
rm -r ~/.kde4/share/apps/nepomuk
nepomukserver

Note que os comandos acima não irão ativar o Nepomuk de forma permanente, caso ele não estivesse anteriormente ativado. Você precisa usar as Configurações do Sistema para fazer isto.

Para que o Akonadi e o Kontact funcionem é necessário que o Nepomuk esteja em execução. No entanto, você pode desativar o indexador de arquivos Strigi, que não é necessário para o Kontact. O indexador de arquivos Strigi é usado apenas para pesquisas no ambiente de trabalho e não possui relação com o Kontact. Certifique-se de que o Nepomuk esteja funcionando corretamente para usar o Kontact.

No Kontact, o Nepomuk é usado para muitas coisas diferentes, que vão desde a exibição dos próximos aniversários, passando pelo gerenciamento de horário livre/ocupado, até a exibição de uma foto do contato no visualizador de mensagens. Se o Nepomuk não estiver em execução, diversas funcionalidades do Kontact não irão funcionar. O aviso está lá para alertá-lo sobre a redução de funcionalidades. O problema é corrigido ao ativar o Nepomuk como descrito acima.

Você pode verificar se o Nepomuk está funcionando corretamente digitando:

akonadictl status

Quero usar o meu livro de endereços e calendário atuais - Posso?

Sim. Quando você usar o Console do Akonadi para adicionar um recurso, ele permiti-lhe escolher como Livro de endereços padrão - direcionar para o seu std.vcf deve funcionar. A migração não destrói o seu livro de endereços antigo. Você pode continuar a usá-lo, mas você perderá todos os benefícios proporcionados pelo Akonadi. Alternativamente, você pode ter o livro de endereços do Akonadi e o seu original ao mesmo tempo, caso se sinta mais seguro desta forma.

Não posso ver nenhum detalhe no meu livro de endereços

No momento, a causa disto não foi identificada, mas a solução é simples. Feche o Kontact e inicie o KAddressBook como um aplicativo independente. Depois de fechado, você será capaz de usá-lo em conjunto com o Kontact. Parece que algo não está sendo acionado ao executar o Kontact, mas esperamos que o problema seja identificado e corrigido em breve. Isto parece afetar principalmente a versão 4.4.0.

Meus contatos não são mostrados quando eu uso o botão Selecionar no KMail

Verifique em Configurações do Sistema -> aba Avançado -> Recursos do KDE. Certifique-se de que o seu livro de endereços controlado pelo Akonadi esteja ali - adicione-o se necessário. Ao mesmo tempo é uma boa ideia tornar padrão o seu livro de endereços Akonadi, normalmente chamado de "Contatos pessoais". Mais detalhes de como fazer isto pode ser encontrado aqui.

Como posso obter novamente o meu livro de endereços Groupware?

Existem duas soluções: usando a plataforma antiga ou a nova.

Plataforma antiga: No akonadiconsole, adicione um "Livro de endereços do KDE (tradicional)". Usar o livro de endereços do KDE permite-lhe configurar o antigo kresources para o Akonadi. Na configuração do "Livro de endereços do KDE (tradicional)", você direciona-o para um KResource "IMAP no KMail" e, no KMail, as opções de groupware devem ser ativadas. Isto deve funcionar para Kolab, eGroupware e livros de endereços similares - você precisa verificar as opções para ter certeza de que o tipo correto está selecionado.

Plataforma nova (testada apenas com o Kolab): Na configuração do módulo do Akonadi, adicione um recurso "Servidor de e-mails IMAP" e defina o nome do seu servidor de e-mails, nome de usuário e senha, então clique em Detectar automaticamente. Execute este comando para carregá-lo:

kcmshell4 kcm_akonadi

Depois adicione um recurso Kolab. O próximo passo é aguardar o recurso imap sincronizar, o que pode levar um longo tempo. O status irá aparecer no módulo de configuração do Akonadi. Se nada aparecer, tente reiniciar o akonadiserver. Após algum tempo, o(s) livro(s) de endereços Kolab devem aparecer no KAddressBook.

Você enfrenta longos atrasos ao enviar e-mails

Isto é acompanhado por congelamento do KMail até que o e-mail seja realmente enviado.

Foi encontrado um erro na forma como o Nepomuk verifica os endereços, que pode causar enormes atrasos. Isto foi corrigido no KDE SC 4.4.1. Se você não pode obter a versão 4.4.1 ainda, aqui tem uma solução temporária:

Feche o Kontact, ou o KMail e o KAddressbook se você estiver executando-os como aplicativos independentes. Desative o Strigi em Configurações do Sistema. Pare o Nepomuk, exclua o banco de dados e reinicie o nepomukserver. Os comandos reais que você precisa são (como usuário):

qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
rm -r ~/.kde/share/apps/nepomuk
rm -r ~/.kde4/share/apps/nepomuk
nepomukserver

Isto irá, é claro, eliminar todo o seu banco de dados, incluindo todas as etiquetas que você adicionou. Em teoria, entende-se que é possível fazer uma limpeza mais seletiva do banco de dados. Se este for importante, você pode encontrar as instruções nesta página

O recurso IMAP sempre alega estar off-line

Mesmo que o sistema tenha uma conexão com a Internet, o recurso IMAP recusa-se a mudar para o status on-line.

Este erro é causado por uma instalação mal configurada do NetworkManager em seu sistema. Verifique o resultado de

qdbus --system org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.state

Se for '4' (Desconectado), mas você pode acessar a Internet, então o seu NetworkManager está de fato configurado incorretamente. Se for '3' (Conectado), o problema deve estar em outro lugar. No Debian, este comportamento pode ser causado por interfaces definidas em /etc/network/interfaces, que não são controladas pelo NetworkManager. Para corrigir isto, simplesmente remova os itens existentes em /etc/network/interfaces e deixe o NetworkManager gerenciar a conexão.

Algumas questões técnicas

Nepomuk

Desde o KDE 4.4 é necessário que o Nepomuk esteja em execução para que o Akonadi funcione corretamente. Caso contrário, o Akonadi irá exibir uma janela de erro na inicialização.

O Nepomuk só funciona com a infraestrutura Virtuoso. É possível verificar se o Nepomuk está funcionando com a infraestrutura correta, com o uso da página de teste automático do Akonadi como descrito acima.

Mesmo que seja necessário manter o Nepomuk em execução, você pode ainda desativar a indexação de arquivos do Strigi, que é a parte que mais consome recursos da plataforma Nepomuk.

Apparmor

Algumas distribuições que usam o Apparmor, o configuram de modo a prevenir que o Akonadi utilize o seu servidor de banco de dados interno. Isto pode resultar em uma grande variedade de mensagens de erro, incluindo as seguintes (entre outras):

unknown error 255 when running akonadictl
"DB error: 'Could not open required defaults file: /home/$username/.local/share/akonadi/mysql.conf"

Você pode solucionar isto ao executar o comando a seguir com privilégios administrativos e depois recarregar o apparmor:

aa-complain mysqld

No Kubuntu seria:

sudo aa-complain mysqld
sudo /etc/init.d/apparmor reload

Lembre-se de que você pode estar usando o Apparmor, mesmo que ele não seja mostrado na sua lista de processos.

Lembre-se também que algumas distribuições disponibilizam um arquivo binário adicional do mysqld chamado mysqld-akonadi, que tem o AppArmor configurado corretamente. Se este for o caso do seu sistema e você ver este problema, existem duas possíveis razões:

• O Akonadi ainda usa o mysqld em vez do mysqld-akonadi. Você pode alterar isto em Configurações do Sistema -> Avançado -> Akonadi -> Configuração do servidor.
• O AppArmor não está corretamente configurado para o mysqld-akonadi. Tente executar o comando "aa-complain" mostrado acima com o mysqld-akonadi no lugar do mysqld.

---

Você também enfrentará esse problema se tiver uma pasta pessoal criptografada usando o encryptfs combinado com o AppArmor, já que o perfil Akonadi apparmor atualmente não pode utilizar uma pasta pessoal criptografada (comum nos usuários do Ubuntu Jaunty). As mensagens de erro são:

• Resultado do dmesg:

ecryptfs_do_create: Failure to create dentry in lower fs; rc = [-13]
ecryptfs_create: Failed to create file inlower filesystem

• O Akonadi apresentará os seguintes erros:

Akonadi server process not registered at D-Bus

A solução para isto passa por editar o arquivo "/etc/apparmor.d/usr.sbin.mysqld-akonadi". Abaixo da linha:

@{HOME}/.local/share/akonadi/** rwk,

Adicione um nova linha:

@{HOME}/.Private/** rwk,

Reinicie o apparmor e o akonadi.

Pré-requisitos ausentes

Para usar o Akonadi, você precisa ter instalados os pacotes a seguir (os nomes podem ser diferentes, dependendo da sua distribuição):

• O servidor MySQL (chamado mysql no openSUSE)
• O plugin Qt4 MySQL (chamado libqt4-sql-mysql no openSUSE)

Se você mesmo compilar o Qt4, certifique-se de informar ao script de configuração a inclusão do suporte ao MySQL, indicando a seguinte opção:

-plugin-sql-mysql

Se a opção "configurar" não puder localizar o código do cliente MySQL necessário (p. ex. apresenta a mensagem "O suporte ao MySQL não pôde ser ativado devido aos testes de funcionalidade"), certifique-se de que o pacote correspondente esteja instalado (normalmente é chamado de [lib]mysql[client]-dev[el]). Além disso, dependendo do local de instalação dos cabeçalhos do MySQL, alguns parâmetros adcionais podem ser necessários para "configuração" (p.ex. "-I /usr/include/mysql" no OpenSuse).

Se você obter o Qt4 diretamente da Nokia, tais como o download do arquivo qt-sdk-linux-x86_64-opensource-2009.05.bin, um erro (através do comando "akonadictl start") será exibido no ao final do Teste 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.

O driver necessário é o libqsqlmysql.so

Lamentavelmente, este driver não faz parte da distribuição (até janeiro de 2010). Você precisa compilar o código-fonte. Baixe o seguinte arquivo:

qt-everywhere-opensource-src-4.6.0.tar.bz

Depois execute configure e make como de costume. Porém, o make install não copia o driver, sendo necessário copiá-lo separadamente:

cp <qt-src-dir>/qt-everywhere-opensource-src-4.6.0/plugins/sqldrivers/libqsqlmysql.so /usr/local/bin/sqldrivers/

Entretanto, a versão 4.6.1, tais como a qt-sdk-linux-x86_64-opensource-2010.xx.bin já possui o driver que você precisa. No entanto, pode ser necessário vincular novamente o libqsqlmysql.so, caso o libmysqlclient.so tenha sido alterado para a nova versão.

Configuração do ambiente

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'

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:

[ERROR] /usr/libexec/mysqld: unknown variable 'innodb_file_per_table=1'
[ERROR] Aborting

Try adding:

#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:

[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 is 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.

On openSUSE 11.2 running the following command will fix this problem:

mysql_install_db --datadir=$HOME/.local/share/akonadi/db_data/

For Archlinux:

mysql_install_db --datadir=$HOME/.local/share/akonadi/db_data/ --basedir=/usr

Kubuntu 10.04 (Lucid Lynx) Upgrade

This is a summary of other entries here for those upgrading from Kubuntu 9.10 to 10.04 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.

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:

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.04 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 is 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 access 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).