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

From KDE Wiki Sandbox
Revision as of 01:39, 22 June 2012 by André Marcelo Alvarenga (talk | contribs) (Created page with "É extremamente difícil diagnosticar, já que a afirmação mencionada acima só aparece às vezes. Em seu lugar, você obterá uma enorme gama de estranhos sintomas: * Registro...")

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

Referência: forum.kde.org Akonadi 1.2.1 - algumas questões

Atualização do KAddressBook

Além da correção do Kubuntu 10.04 acima descrita, para resolver os problemas encontrados ao tentar adicionar uma pasta Vcard, pode ser necessário executar o comando abaixo, enquanto o Akonadi não estiver em execução: 

rm -rf $HOME/.config/akonadi

Não é possível inicializar o conjunto de caracteres latin1

Se obter o erro a seguir enquanto o Akonadi é iniciado, então provavelmente você está usando uma versão do servidor MySQL anterior à 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/)"

Existe uma regressão conhecida no MySQL 5.1.43 e 5.1.44 que impede o MySQL de iniciar.

Veja este relatório de erro para obter mais detalhes.


Reiniciar após um erro anterior

Se você teve problemas para iniciar o Akonadi e conseguiu solucioná-los (tais como um pacote que faltou ou o problema do Apparmor), certifique-se de que o servidor Akonadi está totalmente desligado antes de tentar iniciá-lo novamente, com a execução do comando: 

akonadictl stop

Você pode confirmar que ele foi efetivamente desligado executando: 

akonadictl status

Em algumas circunstâncias o servidor Akonadi pode ficar preso em um estado de funcionamento parcial após uma falha, o que impede que a próxima tentativa de iniciá-lo também falhe. Por favor, cadastre um relatório de erro se você presenciar este problema, incluindo o relatório de teste automático do problema inicial.

O chamado "Gentoo-Assert"

Este é um problema especialmente grave que até agora só afeta usuários de distribuições baseadas em código-fonte, e ocorre principalmente no Gentoo. Teve este nome após as alegações do MySQL, como o exemplo a seguir, e é provavelmente causado por uma incompatibilidade no protocolo MySQL entre o servidor MySQL e a biblioteca cliente ou o driver Qt do MySQL. 

akonadiserver: libmysql.c:4301: setup_one_fetch_function: Assertion
`param->buffer_length != 0' failed.

É extremamente difícil diagnosticar, já que a afirmação mencionada acima só aparece às vezes. Em seu lugar, você obterá uma enorme gama de estranhos sintomas:

  • Registros do protocolo ASAP que mostram a criação com sucesso de objetos que supostamente não estão disponíveis quando os próximos comandos acessá-los novamente.
  • Registros do protocolo SQL que mostram os comandos INSERT ou UPDATE com valores que não coincidem com os correspondentes tipos de colunas e que, no entanto, tem sucesso.
  • Registros do protocolo SQL que mostram registros de IDs aparentemente aleatórios que, no entanto, são considerados válidos.

References:

Possible solution: Rebuild the Qt MySQL driver after upgrading MySQL (which most likely caused this problem in the first place).

Retrieved from "https://wikisandbox.kde.org/index.php?title=Archive:Http://userbase.kde.org/Akonadi_4.4/Troubleshooting/pt-br&oldid=250206"