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.

Mesmo que o sistema tenha uma conexão com a Internet, o recurso IMAP recusa mudar para o estado conectado.

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

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

Você pode obter qualquer um dos seguintes valores:

• 20 (anteriormente 4), desconectado. Se você tiver acesso à internet, a sua configuração do NetworkManager deve estar errada.

• 70 (anteriormente 3), conectado. O problema deve estar em outro lugar.
  • Pode ser que uma ou mais interfaces de rede não são controladas pelo NetworkManager. Se for este o caso, dê o controle destas interfaces ao NetworkManager. Pode ser tão simples como remover os itens para as interfaces de um arquivo de texto (por exemplo, /etc/network/interfaces). Para mais informações, verifique os recursos de ajuda disponibilizados pela sua distribuição.

Não posso ler os detalhes de algumas mensagens ou há uma grande demora para poder lê-los

Se não conseguir ler alguns e-mails e ver uma mensagem com " por favor, aguarde... ", você pode fechar a sessão do KDE e abri-la novamente para reiniciar todos os processos. Isto pode ajudar a resolver o problema.

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.

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 a atualização do MySQL (o que provavelmente causou este problema em primeiro lugar).

Para reiniciar o sistema nepomuk e akonadi no KMail 2

Lembre-se de que você não deve prosseguir com esta dica antes de fazer uma cópia de segurança dos seus dados.

Com a introdução do KMail 2 no kdepim (a partir do KDE SC 4.6.x), para fazer pesquisas em e-mails e obter livros de endereços é necessário ativar Configurações do Sistema -> Pesquisa no desktop -> Ativar o desktop semântico do Nepomuk e marcar o item Ativar indexador de e-mails.

Se o processo virtuoso-t ocupar quase 100% dos núcleos da CPU e o sistema parece estar 'congelado', pode ser uma boa ideia reiniciar tudo.

To do the big reset you need :

Warning

This will initialize all your Kontact and KDE PIM data customization, but not remove emails data, akonadi resources (like email accounts, address books ), KMail Identities, filters and expired mail folders. However, be warned that you will lost much customization information, including ratings and other metadata. Also there is some risk here, because this reconstruction of data has bugs that may make you lose data.

akonadictl stop
rm -rf  ~/.local/share/akonadi/db_data/* 
akonadictl start 
# we should also clean KDE temporary folders before start KMail
rm -rf /var/tmp/kdecache-$USER /tmp/ksocket-$USER /tmp/kde-$USER

You need to check Settings -> Configure KMail -> Identities to see whether the Sent folder is correct. Some of mine were not.

Check Settings -> Configure KMail -> Accounts settings and check whether the incoming folder is correct. Some of mine were not.

Check all filters, before pulling some email. I advise disabling all filters because there may be many folders incorrect or missing.

Also important is that if you have an "expired folder", check all folders to see if the receiving folder is correctly set. If you have Delete permanently checked you may lose important emails because expiring worked with the wrong folder.

In each folder's context menu -> Folder Properties check Identities, as the associated identity may also be changed or lost in any folder.

After this we are ready to clean up Nepomuk data before enabling Nepomuk Semantic.

After all is cleaned , if you aren't able to read any emails, you should logout and login KDE session again to reinitialize all processes .