# Felsökning i &kmail;

## Introduktion till &akonadi;

&kmail; har utvecklats aktivt sedan 1997. Mängder av fel har dykt upp under åren. Många av dem har lösts. Om du är nyfiken på några av de gamla felen, se KMail/FAQs Hints and Tips på &kde;:s användarbas wiki. Eller besök &kde;:s huvudsakliga felspårningssida för att ta reda på mer om fel av senare årgång.

För närvarande (2021) är &akonadi;-servern inblandad i många av problemen som folk upplever med &kmail;. &akonadi; är ett externt program som fungerar som mellanhand mellan &kmail; (samt alla andra program för personlig informationshantering) och en allmän databasdemon (oftast "mysqld"). Det möjliggör också kommunikation mellan processer i de olika delarna av programmen för personlig informationshantering. Beroende på hur systemet är inställt, kan &akonadi; startas vid igångkörnings- eller inloggningsprocessen. Eller så startas det inte förrän du anropar ett program för personlig informationshantering (som &kmail;, Adressboken eller &kontact;).

Det finns två användarprogram som gör det möjligt att direkt interagera med &akonadi;-servern: `akonadictl` (ett terminalbaserat kontrollprogram) och `akonadiconsole` (ett program med grafiskt användargränssnitt). Här är en del information om dessa två program.

### Kontrollprogrammet akonadictl

&akonadi; statusrapport &akonadi; statusrapport

Statusrapport från akonadictl, 32 moduler kör

Föregående skärmbild åskådliggör ett av kommandona man kan använda med programmet `akonadictl`. Här är alla kommandon som `akonadictl` känner igen.

    ~$ akonadictl start

Startar &akonadi;-servern.

    ~$ akonadictl stop

Stoppar &akonadi;-servern.

    ~$ akonadictl restart

Stoppar &akonadi;-servern, och anropar det sedan på nytt.

    ~$ akonadictl status

Producerar statusrapporten som illustrerades på föregående skärmbild.

    ~$ akonadictl instances

Listar &akonadi;-serverns instanser (mer än en kan köra samtidigt).

    ~$ akonadictl vacuum

Städar &akonadi;s lagring, eller försöker åtminstone göra det.

    ~$ akonadictl fsck

Utför en konsistenskontroll av filer. Utdata från kommandot kan vara rätt omfattande, särskilt om du har lagt till egna korgar i &kmail;. Använd den här versionen av kommandot (och skicka utmatningen via grep) för att verifiera att &akonadi;-databasen är frisk, utan att producera en massa ovidkommande utmatning.

    ~ $ 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 betyder fjärridentifierare, ett namngivet fält i mysql-databastabellerna. Om det finns mer än 0 objekt utan RID (items without RID), har du ett mindre problem som bör korrigeras. Om det finns mer än 0 smutsiga objekt (dirty items) kan du ha ett allvarligare problem som måste rättas. Se "Kan inte hämta objekt ..." och även Korrigera &kmail;s "smutsiga" objekt nedan.

### Programmet akonadiconsole

Hur akonadiconsole ser ut Hur akonadiconsole ser ut

Akonadiconsole i arbete

Programmet `akonadiconsole` tillhandahåller tolv olika "fönster" till de inre funktionerna i programmen för personlig informationshantering. Här är en kortfattad sammanfattning av de tillgängliga vyerna.

Fliken Agents.

- Här kan du se en lista av användarmodulerna (processorer).

Fliken Browser,

- Fliken ger en översikt av de olika datasamlingarna som &akonadi; hanterar, organiserat som ett hierarkiskt träd som visar hur många objekt som finns i varje samling.

Fliken Debugger.

- Här kan du sätta på och stänga av avlusning, och visa loggen med avlusningsmeddelanden.

Fliken Logging.

- Fliken låter dig visa meddelanden som kommer från diverse &akonadi;-komponenter.

Fliken DB Browser.

- Använd fliken för att kika in i mysql-databasen. Det finns många olika tabeller.

Fliken DB Console.

- Här kan du skicka förfrågningar till mysql-databasen.

Fliken Query Debugger.

- Använd fliken för att sätta på eller stänga av avlusning. &kmail; skickar förfrågningar till mysql-databasen många gånger under bara några få sekunder, utdata kan vara omfattande.

Fliken Job Tracker.

- Program för personlig informationshantering utför diverse funktioner genom att starta "Jobb". Använd fliken för att sätta på eller stänga av jobbövervakning.

Fliken Resources Schedulers.

- Här kan du se vilka resurser som behövs när en specifik funktion i personlig informationshantering anropas. Du kan ställa in en lista med alla &akonadi;-resurser på systemet i katalogen `~/.config/akonadi/`.

Fliken Notification Monitor.

- Använd fliken för att övervaka underrättelser som skickas av diverse &akonadi;-resurser.

Fliken Item Search.

- Fliken tillhandahåller en generell sökfunktion. Sökningar kan begränsas till Calendar, Contact, Email, eller Note.

Fliken Monitors.

- Här visas en lista över alla övervakare som kör på &akonadi;, och även se deras egenskaper. Moduler, resurser, och även vissa användarprogram övervakas.

## Du får felet "Kunde inte hämta objekt från gränssnitt" vid ingång i &IMAP;-korg

Det finns minst två möjliga orsaker till detta. Här är några provisoriska lösningar.

Lösning 1

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

  - I sektionen [mysql], lägg till: `binlog_format=row`

  Om det inte fungerar prova lösning 2 (nedan).

Lösning 2

- Denna är en fråga om att starta om så att &kmail; kan hämta de där irriterande objekten. Några möjliga steg omfattar:

  Använd &Alt;F2 (Kör program) eller terminalen för att skriva ``kquitapp kmail``, vänta därefter en minut, sedan ``akonadictl stop``. Vänta en minut, skriv ``akonadictl start``, vänta en minut, skriv ``kmail``. Det stoppar &kmail; (och stänger alla fönster), stoppar &kmail;s gränssnitt, startar om &kmail;s gränssnitt, startar om &kmail;. Att ha en fungerade anslutning till Internet ökar chansen att lyckas. Ibland kan du också bara skriva ``kquitapp kmail``, vänta en minut och starta &kmail; igen. Ofta verkar det som ett antal omstarter krävs. Det är oklart vad som orsakar det, men det är troligare att det inträffar med dåliga nätverksanslutningar.

Se också nästa ämne om hur akonadiconsole kan vara till hjälp.

## Brev skickas inte, utan några felmeddelanden

Om &kmail; inte skickar brev utan att säga någonting, kan modulen som ansvarar för att brev levereras ha fastnat. Du måste förstås se till att du har en korrekt nätverksanslutning så att brev kan skickas.

För att åtgärda detta kan det hjälpa att avbryta den pågående åtgärden och starta om den. Avsluta först &kmail; genom att använda Kör program (&Alt;F2) eller terminalen och skriva: ``kquitapp kmail``. Observera att ett vanligt &Alt;F4 eller Arkiv Avsluta inte räcker till! Vänta en minut, starta därefter &kmail; igen. Starta nu akonadiconsole med Kör program (&Alt;F2) eller terminalen. Gå till Mail Dispatcher Agent (under fliken Moduler), högerklicka och avbryt den pågående åtgärden. Du ser troligen ett antal felmeddelanden som dyker upp. Gå nu tillbaka till &kmail; och välj Arkiv Skicka köade brev. Nu kanske det fungerar. Om inte, istället för att avbryta den pågående åtgärden, försök att byta uppkopplingsstatus i Mail Dispatcher Agent eller starta om saker som nämns under lösning 2 av problemet ovanför detta.

akonadiconsole kan vara till stor hjälp i ett antal fall, eftersom den visar alla moduler, de separata komponenterna i &kmail;s gränssnitt. Du kan stoppa och starta dem, placera dem i nerkopplat läge, avbryta pågående åtgärder, etc. Det kan vara till stor hjälp när &kmail; är besvärlig.

Ibland fungerar inte Mail Dispatcher Agent på grund av att dbus-demonen (en funktion för kommunikation mellan processer på systemnivå) inte fungerar som den ska. Under dessa omständigheter är det bäst att helt enkelt starta om systemet. Dbus-demonen är en av de första processerna som startas när du loggar in på &kde;:s skrivbord, så den kan inte enkelt stoppas och startas om. Hela &plasma;-miljön beror på den.

## "Kunde inte hämta objekt från gränssnitt ... [LRCONFLICT]"

Problemet är direkt relaterat till &akonadi; fel nr. 283682, som har varit en nagel i ögat för &kmail; sedan oktober, 2011. Det finns ett problem med timing och koordinering för asynkron behandling av brevfilter. Då och då, gör det att en filterregel som flyttar brev till en annan korg "hickar till", och producerar mer än en databaspost för ett brev som har flyttats. När du försöker öppna den andra kopian av ett sådant brev, visas felmeddelandet "Kunde inte hämta objekt från gränssnitt ... [LRCONFLICT]". Sådana spökbrev kan inte tas bort eller flyttas till papperskorgen med &kmail;s inbyggda funktioner. Men du kan bli av med dem. Så här gör du det.

1. Avsluta först programmet &kmail;. Det kanske inte är nödvändigt, men ta det säkra före det osäkra.

2. Du kan ta reda på hur många skadade brev som finns genom att använda `akonadictl`.

       ~ $ 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 this instance, there are nine duplicated messages (without RID).

3. Du måste veta hur man ansluter direkt till mysql-servern. Använd kommandona `ps` och `grep` för att ta reda på det.

       ~ $ 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. Anropa mysql-serverprogrammet genom att använda uttagsinformationen från steg 3 och utför tre mysql-kommandon, som illustreras nedan.

       ~ $ 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

   De tre mysql-kommandon är "use akonadi;", "delete from pimitemtable where remoteid is NULL;" och "\q". Efter du har skrivit "mysql --socket= ..." är du i dialog med mysql-servern (som också kallas "MariaDB"), som har prompten >. Hela dialogen presenteras här för att vara tydlig. Rader som användaren skrivit in är markerade med <== i exemplet ovan.

När &kmail; startas om är de irriterande duplicerade breven borta. De var enbart spöken skapade av NULL-pekare i mysql-databasens tabeller.

## Hålla &kmail;s extra lagringsområden rena

&kmail; lagrar data på flera olika platser på datorn. De flesta platserna är någonstans inne i katalogen `~/.local/share/`. På många Linux-distributioner finns exempelvis Lokala korgar i `~/.local/share/local-mail/`. &akonadi; lagrar det mesta av sin data i `~/.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` och `Akonadi.error.old` är loggfiler som skapas så fort &akonadi; stoppas och startar om. Textfiler `mysql.conf` är en inställningsfil för mysqld-demonen som fungerar som &akonadi;s gränssnitt. De två katalogerna `db_data` och `search_db` innehåller själva mysql- databasens tabeller. Det finns också några mysql loggfiler i `db_data` som kan vara till hjälp om och när &akonadi; krånglar.

De två katalogerna `file_db_data` och `file_lost+found` innehåller extra data associerad med asynkron behandling. &akonadi; rensar inte automatiskt katalogen `file_lost+found`, så du kanske ska rensa bort filerna manuellt då och då (t.ex. med &dolphin;). &akonadi; försöker rensa katalogen `file_db_data` efter allt har sammanfogas allt i huvuddatabasens filer, men ibland samlas skräp där. Använd kommandot

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

för att fixa det när det inträffar (om katalogen `file_db_data` redan är tom, returnerar kommandot "find" ovan ett fel).

## Korrigera &kmail;s "smutsiga" objekt

Problemet är direkt relaterat till &akonadi; fel nr. 436550, som rapporterades april, 2021. Det orsakas av de "smutsiga" objekten som ibland hittas av `akonadictl fsck`.

    ~ $ 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.

Flaggan "dirty" för ett objekt i pimitemtable (en av tabellerna i &akonadi;-databasen) används för att hantera vissa aspekter av asynkron behandling. Den tilldelas true när åtgärder väntar för ett specifikt e-postbrev. Oftast nollställs flaggan "dirty" en eller två sekunder senare, när den väntande åtgärden avslutas.

Ibland, av orsaker som inte är helt klargjorda, kan flaggan "dirty" tilldelas till dussintals eller till och med hundratals brev samtidigt, som åskådliggörs ovan. När det inträffar, fastnar den automatiska mekanismen för att nollställa dem, och kan inte reparera sig själv automatiskt. Den primära orsaken för ett "smutsigt" objekt i detta fall är att fältet "remoteid" inte är riktigt inställt, vilket gör det omöjligt att hämta ett "smutsigt" brev i &kmail;. Brevet finns fortfarande på disk, men &kmail; kan inte hitta det.

Det borde finnas ett bättre sätt att korrigera problemet. Om du kommer på ett bättre sätt, låt författarna få reda på det, så att dokumentationen kan förbättras. Följande procedur rättar åtminstone databasfelen. Men den innebär en hel del arbete.

1. Avsluta &kmail; och stoppa &akonadi;-servern med ett terminalkommando: `akonadictl stop`.

2. Skapa en säkerhetskopia av alla dina e-postbrev. Du kan kanske använda Export av data för personlig informationshantering för att göra det. Eller så kan du använda &ark; för att skapa ett arkiv, eller &dolphin; för att skapa en andra kopia av `~/.local/share/local-mail/` någon annanstans på hårddisken. Om du är äventyrlig, kan du bara byta namn på din lokala korgkatalog till något som `local-mail-sparade`. Men det är säkrare att försäkra dig om att det finns en säkerhetskopia av dina brev innan du fortsätter.

3. Du bör också göra en säkerhetskopia av eventuella filter du har skapat, och säkerställa att du vet hur man återställer eventuella egna korgar med Skickade brev, Utkast eller Mallar som hör ihop med dina identiteter i &kmail;. Nästa steg tar bort alla dina personliga anpassade brevkorgar, och du måste laga en del efter &akonadi; har byggt om sina databastabeller.

4. Ta nu bort alla korgar under katalogen `local-mail`, eller byt namn på katalogen till något som `local-mail-sparade` . Starta därefter programmet &kmail;. Det tvingar &akonadi; att radera alla databasens tabellposter som hör ihop med e-postbrev. Du ser dina gamla korgnamn under en kort tid, men de försvinner när &akonadi; är klar med att ta bort alla "smutsiga" objekt (och även alla rena).

5. Avsluta &kmail; och stoppa &akonadi;-servern som förklaras under steg 1, återställ därefter säkerhetskopian av dina brev (skapad i steg 2) i katalogen `~/.local/share/local-mail/`.

6. Starta &kmail; igen, och tvinga &akonadi; att synkronisera om databasen. Det enklaste sättet att göra det är att använda &Ctrl;L Arkiv Kontrollera post. &akonadi; synkroniserar automatiskt alla korgar när nya brev hämtas. Det tar flera minuter att slutföra, beroende på hur många brev du har sparat i dina &kmail;-korgar. Men när processen är färdig har alla "smutsiga" objekt försvunnit.

7. Slutligen, ska du återställa dina e-postfilterregler säkerhetskopierade i steg 3, och kontrollera att alla egna korgobjekt (Skickade brev, etc.) är inställda som du vill ha dem. Du måste också återställa eventuella egna korgegenskaper du hade ställt in, och du har troligen ett antal felaktiga underrättelser om "olästa brev" att ta hand om. Men dina &akonadi; databastabeller är riktigt rena och snygga igen!