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

O servidor Akonadi procura por agentes e recursos do Akonadi nos locais definidos na variável de ambiente XDG_DATA_DIRS. Se o Akonadi informar que não conseguiu localizar os agentes e recursos, verifique se esta variável está definida corretamente. Caso isto tenha sido definido na sessão atual do console, lembre-se de que pode não ter sido ativado quando o servidor foi iniciado. Iniciar o servidor diretamente na sessão atual do console pode solucionar este problema.

mysqld: unknown variable 'innodb_file_per_table=1'

Se o arquivo de registro (log) do servidor MySQL conter o erro a seguir, então o seu servidor MySQL foi compilado sem suporte ao InnoDB, que é utilizado pelo Akonadi ou o InnoDB e precisa ser carregado a partir do seu arquivo mysql.conf:

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

Tente adicionar:

#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

A tabela 'mysql.servers' não existe

Se o registro do servidor MySQL contém os erros a seguir, provavelmente, você não tem o arquivo de configuração do MySQL no seu lugar:

[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

Copie ele de /usr/share/config/akonadi/mysql-global.conf para ~/.config/akonadi/mysql-local.conf. (Para usuários do Debian e OpenSUSE, o arquivo está localizado em /etc/akonadi/mysql-global.conf). Abra-o e retire o indicador de comentário da linha sql_mode=strict_trans_tables. Após isto, você poderá obter os seguintes erros.

[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported table type: innodb
[ERROR] Aborting

Se afirmativo, então procure no mesmo arquivo a linha que começa exatamente como descrito acima (aquela que você retirou o indicador de comentário), mas tem parâmetros adicionais separados por vírgula (algo parecido com sql_mode=strict_trans_tables,strict_all_tables, ...etc). Inclua um indicador de comentário na linha curta sql_mode=... e retire o indicador da linha longa.

No OpenSUSE 11.2 execute o comando a seguir para corrigir este problema:

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

Para o Archlinux:

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

Atualização do Kubuntu 10.04 (Lucid Lynx)

Isto é um resumo de outras entradas para quem atualizar do Kubuntu 9.10 para o 10.04, que estejam usando um arquivo de pacote pessoal (PPA) do KDE 4.3 para correção de erros.

Instale os pré-requisitos que faltam, remova a cache anterior do akonadi e inicie o serviços akonadi. Instale o banco de dados e atualize-o. Pare e reinicie o serviço 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

O comando mysql_install_db mostrado acima irá informar algo como o descrito abaixo, que poderá ser ignorado com segurança:

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).