Delen van dit hoofdstuk zijn geconverteerd uit de KDE UserBase pagina KMail/FAQs Hints and Tips in 2012.
&David.Bryant; &David.Bryant.mail;
&Freek.de.Kruijf;
2021-08-08
5.14.2 (Applications 20.04.2)

# &kmail; probleemoplossing

## Inleiding in &akonadi;

&kmail; is actief in ontwikkeling sinds 1997. Heel wat bugs zijn over de jaren opgedoken. Veel ervan zijn opgelost. Als u nieuwsgierig bent naar een van deze oude bugs, kijk dan op KMail/FAQs Hints and Tips in de UserBase Wiki van &kde;. Of bezoek hoofd bug volgpagina van &kde; om meer te weten te komen over bugs met een recentere datum.

Op dit moment (2021) hebben veel problemen die mensen tegenkomen met &kmail; te maken met de &akonadi;-server. &akonadi; is een extra programma dat als een intermediair tussen &kmail; (plus alle andere &PIM; toepassingen) en een database-daemon voor algemene doelen functioneert (gewoonlijk "mysqld"). Het faciliteert communicatie tussen processen onder de verschillende stukjes van de &PIM; toepassingen. Afhankelijk van de manier waarop uw systeem is geconfigureerd, kan &akonadi; gestart worden tijdens de opstart van het systeem / het aanmeldproces. Of het kan niet gestart worden totdat u een &PIM; toepassingsprogramma (zoals &kmail;, of &kaddressbook; of &kontact;) opstart.

Er zijn twee toepassingsprogramma's die u directe interactie met de &akonadi;-server biedt: `akonadictl` (een terminal georiënteerd besturingsprogramma) en `akonadiconsole` (een GUI toepassing). Hier enige informatie over deze twee programma's.

### Het Akonadictl besturingsprogramma

&akonadi; statusrapport
&akonadi; statusrapport

Akonadictl statusrapport, 32 agenten actief

De voorgaande schermafdruk illustreert een van de commando's die gebruikt kunnen worden met het programma `akonadictl`. Hier zijn alle commando's die `akonadictl` herkent.

    ~$ akonadictl start

Start de &akonadi;-server.

    ~$ akonadictl stop

Stopt de &akonadi;-server.

    ~$ akonadictl restart

Stopt de &akonadi;-server en start deze als nieuw.

    ~$ akonadictl status

Produceert het statusrapport geïllustreerd in de voorgaande schermafdruk.

    ~$ akonadictl instances

Geeft een lijst met exemplaren van &akonadi;-server (meer dan één kunnen tegelijk actief zijn).

    ~$ akonadictl vacuum

Schoont de opslag van &akonadi; op of probeert dat tenminste.

    ~$ akonadictl fsck

Er wordt een controle op consistentie van het bestand gedaan. De uitvoer van dit commando kan behoorlijk veel zijn, speciaal als u uw eigen mappen aan &kmail; hebt toegevoegd. Gebruik deze version van het commando (met pipe van de uitvoer door grep) om te verifiëren dat uw &akonadi; database gezond is, zonder veel overbodige uitvoer.

    ~ $ akonadictl fsck 2
    >&1 | grep ^Found
    Found 0 external files.
    Found 0 external parts.
    Found no unreferenced external files.
    Found 0 parts to be moved to external files
    Found 0 parts to be moved to database
    Found 6 collections without RID.
    Found 0 items without RID.
    Found 0 dirty items.

RID staat voor RemoteId, een veld met een naam in de mysql database tabellen. Als er meer dan 0 items zonder RID zijn, hebt u een klein probleem dat gecorrigeerd zou moeten worden. Als er meer dan 0 dirty items zijn kunt u een groter probleem hebben dat gecorrigeerd moet worden. Zie "Item ophalen lukt niet..." en ook "Dirty" items van &kmail; corrigeren, zie onderstaand.

### Het programma Akonadiconsole

Hoe akonadiconsole er uit ziet
Hoe akonadiconsole er uit ziet

Akonadiconsole in actie

Het programma `akonadiconsole` levert twaalf verschillende "vensters" in de interne werking van de &PIM; toepassingen. Hier is een korte samenvatting van de beschikbare beelden.

Tabblad Agents.

  Hier ziet u een lijst met de gebruikersagenten (processoren).

Tabblad Bladeren.

  Dit tabblad levert een overzicht van de verschillende verzamelingen gegevens die &akonadi; beheert, georganiseerd als een hiërarchische boomstructuur die toont hoeveel items er zich in elke verzameling bevinden.

Tabblad Debugger.

  Hier kunt u debugging aan en uit zetten en de debugberichtenlog bekijken.

Tabblad Logging.

  Dit tabblad laat u berichten uitgezonden door verschillende &akonadi; componenten bekijken.

Tabblad DB-browser.

  Dit tabblad gebruiken om in de mysql database te gluren. Er zijn veel verschillende tabellen.

Tabblad DB console.

  Hier kunt u de mysql database bevragen.

Tabblad Query debugger.

  Dit tabblad gebruiken om query-debugging aan en uit te zetten. &kmail; bevraagt de mysql database vele keren in enkele seconden; uitvoer kan veel zijn.

Tabblad Takenvolger.

  De &PIM; toepassingen voeren verschillende functies uit door "taken" te initiëren. Dit tabblad gebruiken om taken volgen aan en uit te zetten.

Tabblad Planners van hulpbronnen.

  Hier kunt u zien welke hulpbronnen nodig zijn wanneer een specifieke &PIM; functie wordt aangeroepen. U kunt een lijst met alle hulpbronnen van &akonadi; in uw systeem zien in de map `~/.config/akonadi/`.

Tabblad Meldingenmonitor.

  Dit tabblad gebruiken om meldingen te monitoren verzonden door verschillende hulpbronnen van &akonadi;.

Tabblad Item zoeken.

  Dit tabblad biedt een generieke zoekfunctie. Zoekopdrachten kunnen beperkt worden tot Agenda, Contactpersonen, E-mail of Notitie.

Tabblad Monitoren.

  Hier kunt u een lijst van alle monitoren die onder &akonadi; actief zijn bekijken evenals hun eigenschappen. Agenten, hulpbronnen en zelfs enige toepassingsprogramma's worden gemonitord.

## "Item ophalen uit de backend" wanneer u een IMAP-map ingaat

Er zijn hiervoor minstens twee mogelijke redenen. Hier zijn enige omwegen.

Workaround 1

  - bewerk `~/.local/share/akonadi/mysql.conf`

  - Onder de sectie [mysql] voeg toe: `binlog_format=row`

  Als dat niet werkt, probeer workaround 2 (onderstaand).

Workaround 2

  Hierbij is het zaak om opnieuw op te starten zodat &kmail; de vervelende items kan ophalen. Enkele mogelijke stappen zijn:

  Gebruik &Alt;F2 (&krunner;) of &konsole; om te typen: ``kquitapp kmail``, wacht dan een minuut, dan ``akonadictl stop``. Wacht een minuut, typ ``akonadictl start``, wacht een minuut, typ ``kmail``. Dit stopt &kmail; (met het sluiten van alle vensters), stopt de backend van &kmail;, herstart deze en herstart &kmail;. Met een werkende internetverbinding wordt de kans op succes vergroot. Soms kunt u ook gewoon ``kquitapp kmail`` doen, wacht een minuut en start &kmail; opnieuw. Vaak is er een paar keer opnieuw starten nodig. Het is onduidelijk wat de reden van deze fout is, maar met een slechte netwerkverbinding is het meer waarschijnlijk.

Zie ook het onderstaande onderwerp voor hoe akonadiconsole behulpzaam kan zijn.

## Uw e-mails worden niet verzonden, zonder foutmeldingen

Als &kmail; geen e-mail verzendt zonder iets te melden, dan is de agent verantwoordelijk voor het versturen van de berichten vastgelopen. Natuurlijk moet u nagaan dat u een werkende netwerkverbinding hebt zodat u e-mail kunt verzenden!

Om dit te verhelpen kan het zijn dat de huidige actie afbreken en opnieuw starten helpt. Beëindig als eerste &kmail; door &krunner; te gebruiken (&Alt;F2) of &konsole; en invoeren van: ``kquitapp kmail``. Merk op dat een normale &Alt;F4 of Bestand Afsluiten niet helpt! Wacht een minuut, start dan &kmail; opnieuw. Start dan akonadiconsole met &krunner; (&Alt;F2) of &konsole;. Ga naar de Agent voor het verzenden van e-mail (onder het tabblad Agenten), klik rechts en breek de huidige actie af. U zult waarschijnlijk een soort foutmelding zien verschijnen. Ga nu terug naar &kmail; en kies Bestand Berichten in wachtrij verzenden. Nu zou het kunnen werken. Zo niet, in plaats van de huidige actie afbreken, probeer de status offline/online van de genoemdAgent voor het verzenden van e-mail (hetzelfde contextmenu) om te schakelen of start de dingen opnieuw zoals eerder genoemd in de workaround 2 van het eerdere probleem.

akonadiconsole kan erg behulpzaam zijn voor een aantal situaties omdat het alle agenten toont, de separate componenten van de backend van &kmail;. U kunt ze stoppen en starten, ze in een modus offline zetten, gaande acties afbreken &etc;. Het kan zeer behulpzaam zijn wanneer &kmail; vreemd reageert.

Soms werkt de Agent voor het verzenden van e-mail niet goed omdat de dbus-daemon (een faciliteit op systeemniveau voor communicatie tussen processen) niet juist functioneert. Uw beste gok in deze omstandigheid is eenvoudig het systeem opnieuw opstarten. De dbus-daemon is een van de eerste processen die worden gestart wanneer u zich aanmeldt in het bureaublad van &kde;, zodat het niet gemakkelijk gestopt en herstart kan worden. De gehele &plasma; omgeving hangt er vanaf.

## "Item ophalen uit de backend ... [LRCONFLICT]"

Dit probleem is direct gerelateerd aan &akonadi; bug #283682, die een nagel aan de doodskist van &kmail; is sinds oktober, 2011. Er is een probleem met timing / coördinatie tussen asynchroon verwerken van berichtfilters. Af en toe is er een filterregel die berichten naar een andere map verplaatst "hiccups (verslikt zich)" en produceert meer dan één database item voor een bericht dat verplaatst is. Wanneer u de tweede kopie van zo'n bericht opent, verschijnt de foutmelding "Item ophalen uit de backend ... [LRCONFLICT]". Zo'n spookbericht kan niet verwijderd of verplaatst worden naar de prullenbak met ingebouwde functies van &kmail;. Maar u kunt ze kwijtraken. Hier is hoe u dat doet.

1. Sluit het programma &kmail; af. Dis misschien niet nodig, maar beter veilig dan sorry.

2. U kunt te weten komen hoeveel corrupte berichten er aanwezig zijn door `akonadictl` te gebruiken.

       ~ $ akonadictl fsck 2
       >&1 | grep ^Found
       Found 6 external files.
       Found 6 external parts.
       Found no unreferenced external files.
       Found 0 parts to be moved to external files
       Found 0 parts to be moved to database
       Found 6 collections without RID.
       Found 9 items without RID.
       Found 0 dirty items.

   In dit exemplaar zijn er negen gedupliceerde berichten (zonder RID).

3. U moet weten hoe direct een verbinding te maken met de mysql-server. Gebruik de commando's `ps` en `grep` om dat te doen.

       ~ $ ps ux | grep mysql
       david     8788  0.2  0.9 3736292 153936 ?      Sl   06:45   0:16 /usr/sbin/mysqld
       --defaults-file=/home/david/.local/share/akonadi/mysql.conf
       --datadir=/home/david/.local/share/akonadi/db_data/
       --socket=/run/user/1000/akonadi/mysql.socket
       --pid-file=/run/user/1000/akonadi/mysql.pid
       david    24275  0.0  0.0   8056  2144 pts/1    S+   08:24   0:00 grep --colour=auto mysql

4. Gebruik het serverprogramma mysql met de socketinformatie uit stap 3 en geeft drie mysql commando's, zoals onderstaand geïllustreerd.

       ~ $ mysql --socket=/run/user/1000/akonadi/mysql.socket                  <==
       Welcome to the MariaDB monitor.  Commands end with ; or \g.
       Your MariaDB connection id is 114
       Server version: 10.5.10-MariaDB Source distribution

       Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

       Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

       MariaDB [(none)]> use akonadi;                                         <==
       Reading table information for completion of table and column names
       You can turn off this feature to get a quicker startup with -A

       Database changed
       MariaDB [akonadi]> delete from pimitemtable where remoteid is NULL;    <==
       Query OK, 9 rows affected (0.003 sec)

       MariaDB [akonadi]> \q                                                  <==
       Bye

   The drie mysql commando's zijn "use akonadi;", "delete from pimitemtable where remoteid is NULL;" en "\q". Nadat u "mysql --socket= ..." ingeeft zult u in een dialoog komen met de mysql-server (aka "MariaDB"), die een prompt > laat zien. De gehele dialoog is hier, voor de helderheid, gepresenteerd. Ingevoerde regels zijn gemarkeerd met <== in de voorgaande illustratie.

Wanneer u &kmail; herstart zijn deze pesterige gedupliceerde berichten verdwenen. Het waren eigenlijk fantomen veroorzaakt door de NULL pointers in de mysql database tabellen.

## Extra opslaggebieden van &kmail; schoon houden

&kmail; slaat gegevens op op verschillende plaatsen op uw machine op. De meeste van deze plaatsen zijn ergens in de map `~/.local/share/`. Op de meeste Linux distributies zitten uw Lokale mappen in `~/.local/share/local-mail/` . &akonadi; slaat het meeste van zijn gegevens op in `~/.local/share/akonadi/` .

    ~ $ cd .local/share/akonadi
    ~/.local/share/akonadi $ ls
    Akonadi.error      db_data  file_db_data     mysql.conf  socket-localhost-default
    Akonadi.error.old  db_misc  file_lost+found  search_db

`Akonadi.error` en `Akonadi.error.old` zijn logbestanden die gemaakt worden wanneer &akonadi; stopt en opnieuw start. Tekstbestand `mysql.conf` is een configuratiebestand voor de mysqld-daemon die dienst als de backend van &akonadi;. De twee mappen `db_data` en `search_db` bevatten de actuele mysql database tabellen. Er zijn ook een aantal mysql logbestanden in `db_data` die kunnen helpen als en wanneer &akonadi; vreemd doet.

De twee mappen `file_db_data` en `file_lost+found` bevatten extra gegevens geassocieerd met asynchrone verwerking. &akonadi; schoont de map `file_lost+found` niet automatisch op, u zou deze bestanden handmatig zo af en toe kunnen opschonen (&eg;, with &dolphin;). &akonadi; probeert de map `file_db_data` op te schonen nadat het alles in de hoofddatabasebestanden heeft samengevoegd, maar soms blijft er daar rommel zich opstapelen. Gebruik dit commando

    find .local/share/akonadi/file_db_data/ -type f | xargs rm

om dit te repareren wanneer het gebeurt. (Als de map `file_db_data` al schoon is, zal het commando "find", boven getoond, een fout tonen.)

## "Dirty" items in &kmail; corrigeren

Dit probleem is direct gerelateerd aan &akonadi; bug #436550, die gerapporteerd is in april, 2021. Het komt van de "dirty" items die zo af en toe door `akonadictl fsck` gevonden worden.

    ~ $ akonadictl fsck 2
    >&1 | grep ^Found
    Found 5 external files.
    Found 5 external parts.
    Found no unreferenced external files.
    Found 0 parts to be moved to external files
    Found 0 parts to be moved to database
    Found 6 collections without RID.
    Found 0 items without RID.
    Found 750 dirty items.

De vlag "dirty" op een item in pimitemtable (een van de tabellen in de &akonadi; database) wordt gebruikt om bepaalde aspecten van asynchrone verwerking te controleren. Deze is op true is gezet wanneer er bewerkingen staan te wachten voor een bepaald e-mailbericht. Meestal wordt de vlag "dirty" een of twee seconden later gewist, wanneer de eens wachtende bewerking beëindigd wordt.

Af en toe, voor redenen die niet geheel helder zijn, kan de vlag "dirty" gezet worden op tientallen of zelfs honderden berichten alles ineens, zoals boven aangegeven. Wanneer dat gebeurt zal het automatische wismechanisme vastlopen en is is niet in staat om zichzelf automatisch te repareren. De primaire reden voor een "dirty" item in deze omstandigheden is dat het veld "remoteid" niet juist is gezet, waardoor ophalen van een "dirty" bericht onmogelijk is in &kmail;. Het bericht bestaat nog steeds op de schijf. Maar &kmail; kan het niet vinden.

Er zout een betere manier moeten zijn om dit probleem te corrigeren. Als u een betere manier weet, laat het dan de auteurs weten, zodat deze documentatie verbeterd kan worden. De volgende procedure zal tenminste de databasefouten corrigeren. Maar het vraagt heel wat werk.

1. Beëindig &kmail; en stop de &akonadi; server met een terminalcommando: `akonadictl stop` .

2. Maak een reservekopie van al uw e-mailberichten. U zou PIM gegevensexporteur voor dit doel kunnen gebruiken. Of u kunt &ark; gebruiken om een archief te maken of &dolphin; om een tweede kopie van `~/.local/share/local-mail/` ergens anders op uw vaste schijf. Als u van avonturen houdt, zou u uw lokale mappen direct naar iets als `local-mail-save` kunnen hernoemen. Maar het is veiliger om zeker te zijn dat u een reservekopie van uw berichten hebt alvorens u verder gaat.

3. U zou ook een reservekopie van alle filters die u hebt gemaakt kunnen maken en nagaan dat u weet hoe aangepaste items Map Verzonden e-mail, Map Concepten of Map Sjablonen geassocieerd met uw &kmail; identiteiten herstelt. De volgende stap zal al uw persoonlijk aangepaste e-mailmappen verwijderen en u zult enige zaken moeten aanpassen nadat &akonadi; zijn databasetabellen opnieuw bouwt.

4. Verwijder nu alle mappen in de map `local-mail` of hernoem die map tot iets zoals `local-mail-save` . Start daarna het programma &kmail;. Dit dwingt &akonadi; om alle databasetabelitems geassocieerd met e-mailberichten te wissen. U zult uw oude mapnamen zien, kort, maar deze zullen verdwijnen wanneer &akonadi; eindigt met het verwijderen van alle "dirty" items (en alle schone, ook).

5. Beëindig &kmail; en stop de &akonadi; server zoals uitgelegd in stap 1, herstel daarna de reservekopie van uw berichten (aangemaakt in stap 2) naar de map `~/.local/share/local-mail/` .

6. &kmail; opnieuw opstarten en afdwingen dat &akonadi; zich opnieuw synchroniseert met de database. De gemakkelijkste manier om dat te doen is &Ctrl;L Bestand E-mail controleren; &akonadi; synchroniseert automatisch alle mappen wanneer het e-mail ophaalt. Dit kan een aantal minuten duren om te voltooien, afhankelijk van hoeveel berichten u hebt opgeslagen in uw mappen in &kmail;. Maar wanneer het proces gereed is zullen alle "dirty" items weg zijn.

7. Tenslotte zult u uw e-mailfilterregels wille herstellen waarvan een reservekopie in stap 3 is gemaakt en controleer dat alle aangepaste mapitems (Map Verzonden e-mail, &etc;) voor uw identiteiten ingesteld zijn op de manier die u wilt. Het is ook nodig om elke aangepaste mapeigenschap die u hebt ingesteld terug te zetten en u zult waarschijnlijk wat moeten doen met een aantal onverwachte "Ongelezen bericht" meldingen. Maar uw &akonadi; databasetabellen zullen weer schoon en glanzend zijn!