Archive:Http://userbase.kde.org/Akonadi 4.4/Troubleshooting/pt-br: Difference between revisions
(Created page with "Referências: * http://forum.kde.org/viewtopic.php?f=20&t=61738 * http://bugs.gentoo.org/show_bug.cgi?id=267513 * https://bugs.kde.org/202623 (contém uma possível solução) * ...") |
(Created page with "Possível solução: Recompile o driver Qt do MySQL após atualizar o MySQL (o que provavelmente causa este problema em primeiro lugar).") |
||
Line 324: | Line 324: | ||
* http://bbs.archlinux.org/viewtopic.php?id=78358 | * http://bbs.archlinux.org/viewtopic.php?id=78358 | ||
Possível solução: Recompile o driver Qt do MySQL após atualizar o MySQL (o que provavelmente causa este problema em primeiro lugar). | |||
[[Category:Sistema/pt-br ]] | [[Category:Sistema/pt-br ]] |
Revision as of 01:42, 22 June 2012
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.
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:
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 aqui.
. 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 encontradoComo 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 .
- 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.
Referências:
- http://forum.kde.org/viewtopic.php?f=20&t=61738
- http://bugs.gentoo.org/show_bug.cgi?id=267513
- https://bugs.kde.org/202623 (contém uma possível solução)
- http://bbs.archlinux.org/viewtopic.php?id=78358
Possível solução: Recompile o driver Qt do MySQL após atualizar o MySQL (o que provavelmente causa este problema em primeiro lugar).