Akonadi

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Akonadi

selist

Hallo,

Akonadi startet hier nicht richtig. Folgende Fehlermeldungen erhalte ich beim Start von Kontact.


MYSQL Serverprotokoll enthält Fehler.

170526 13:48:01 [Note] InnoDB: Using mutexes to ref count buffer pool pages
170526 13:48:01 [Note] InnoDB: The InnoDB memory heap is disabled
170526 13:48:01 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
170526 13:48:01 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
170526 13:48:01 [Note] InnoDB: Compressed tables use zlib 1.2.11
170526 13:48:01 [Note] InnoDB: Using Linux native AIO
170526 13:48:01 [Note] InnoDB: Not using CPU crc32 instructions
170526 13:48:01 [Note] InnoDB: Initializing buffer pool, size = 80.0M
170526 13:48:01 [Note] InnoDB: Completed initialization of buffer pool
170526 13:48:01 [Note] InnoDB: Highest supported file format is Barracuda.
170526 13:48:01 [Note] InnoDB: Log scan progressed past the checkpoint lsn 7035871685
170526 13:48:01 [Note] InnoDB: Database was not shutdown normally!
170526 13:48:01 [Note] InnoDB: Starting crash recovery.
170526 13:48:01 [Note] InnoDB: Reading tablespace information from the .ibd files...
170526 13:48:01 [Note] InnoDB: Restoring possible half-written data pages
170526 13:48:01 [Note] InnoDB: from the doublewrite buffer...
170526 13:48:06 [ERROR] InnoDB: Tried to read 16384 bytes at offset 64208896. Was only able to read 12288.
2017-05-26 13:48:06 7f7699b06740 InnoDB: Operating system error number 5 in a file operation.
InnoDB: Error number 5 means 'Input/output error'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
170526 13:48:06 [ERROR] InnoDB: File (unknown): 'read' returned OS error 105. Cannot continue operation

Akonai-Steuerprogram nicht am D-Bus registriert

Das Akonadi-Steuerprogramm ist nicht am D-Bus registriert, was normalerweise bedeutet, dass es nicht gestartet wurde oder beim Start ein schwerer Fehler aufgetreten ist.



Database process exited unexpectedly during initial connection!
executable: "/usr/sbin/mysqld"
arguments: ("--defaults-file=/home/sebastian/.local/share/akonadi/mysql.conf", "--datadir=/home/sebastian/.local/share/akonadi/db_data/", "--socket=/tmp/akonadi-sebastian.P5dJCT/mysql.socket")
stdout: ""
stderr: "170526 13:48:01 [Note] /usr/sbin/mysqld (mysqld 10.0.30-MariaDB) starting as process 31402 ...
"
exit code: 1
process error: "Process operation timed out"
"[
0: akonadiserver(_Z11akBacktracev+0x4b) [0x463a6b]
1: akonadiserver() [0x463cf2]
2: /lib64/libc.so.6(+0x331f0) [0x7f4ed4fae1f0]
3: /lib64/libc.so.6(gsignal+0x37) [0x7f4ed4fae167]
4: /lib64/libc.so.6(abort+0x16a) [0x7f4ed4faf5ea]
5: /usr/lib64/qt4/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x8d) [0x7f4ed68ae18d]
6: akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0xad) [0x465bad]
7: /usr/lib64/qt4/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0x9f) [0x7f4ed6954b9f]
8: /usr/lib64/qt4/libQtCore.so.4(+0x125cb5) [0x7f4ed6962cb5]
9: /usr/lib64/qt4/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x31) [0x7f4ed696c9f1]
10: akonadiserver(_ZN6QDebugD1Ev+0x48) [0x45e7c8]
11: akonadiserver(_ZN7Akonadi6Server13DbConfigMysql19startInternalServerEv+0x1ecb) [0x4d53ab]
12: akonadiserver(_ZN7Akonadi6Server13AkonadiServer20startDatabaseProcessEv+0xff) [0x46681f]
13: akonadiserver(_ZN7Akonadi6Server13AkonadiServer4initEv+0xb8) [0x468ed8]
14: akonadiserver() [0x536719]
15: /usr/lib64/qt4/libQtCore.so.4(_ZN7QObject5eventEP6QEvent+0x1d1) [0x7f4ed69e9871]
16: /usr/lib64/qt4/libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x8c) [0x7f4ed69cf0ac]
17: /usr/lib64/qt4/libQtCore.so.4(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x365) [0x7f4ed69d2625]
18: /usr/lib64/qt4/libQtCore.so.4(+0x1c343e) [0x7f4ed6a0043e]
19: /usr/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x244) [0x7f4ed4678384]
20: /usr/lib64/libglib-2.0.so.0(+0x4c665) [0x7f4ed4678665]
21: /usr/lib64/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x7f4ed467872c]
22: /usr/lib64/qt4/libQtCore.so.4(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x7e) [0x7f4ed6a005be]
23: /usr/lib64/qt4/libQtCore.so.4(_ZN10QEventLoop13processEventsE6QFlagsINS_17ProcessEventsFlagEE+0x41) [0x7f4ed69cd821]
24: /usr/lib64/qt4/libQtCore.so.4(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x1b5) [0x7f4ed69cdbd5]
25: /usr/lib64/qt4/libQtCore.so.4(_ZN16QCoreApplication4execEv+0x99) [0x7f4ed69d3799]
26: akonadiserver(main+0x1e5) [0x45dbe5]
27: /lib64/libc.so.6(__libc_start_main+0xf0) [0x7f4ed4f9b790]
28: akonadiserver(_start+0x29) [0x45e509]
]
"


Gruß
Sebastian

Reply | Threaded
Open this post in threaded view
|

Re: Akonadi

Kai Krakow
Am Fri, 26 May 2017 13:58:05 +0200 (CEST)
schrieb Sebastian Kürschner <[hidden email]>:

> Hallo,
>
> Akonadi startet hier nicht richtig. Folgende Fehlermeldungen erhalte
> ich beim Start von Kontact.
>
>
> MYSQL Serverprotokoll enthält Fehler.
>
> 170526 13:48:01 [Note] InnoDB: Using mutexes to ref count buffer pool
> pages 170526 13:48:01 [Note] InnoDB: The InnoDB memory heap is
> disabled 170526 13:48:01 [Note] InnoDB: Mutexes and rw_locks use GCC
> atomic builtins 170526 13:48:01 [Note] InnoDB: GCC builtin
> __atomic_thread_fence() is used for memory barrier 170526 13:48:01
> [Note] InnoDB: Compressed tables use zlib 1.2.11 170526 13:48:01
> [Note] InnoDB: Using Linux native AIO 170526 13:48:01 [Note] InnoDB:
> Not using CPU crc32 instructions 170526 13:48:01 [Note] InnoDB:
> Initializing buffer pool, size = 80.0M 170526 13:48:01 [Note] InnoDB:
> Completed initialization of buffer pool 170526 13:48:01 [Note]
> InnoDB: Highest supported file format is Barracuda. 170526 13:48:01
> [Note] InnoDB: Log scan progressed past the checkpoint lsn 7035871685
> 170526 13:48:01 [Note] InnoDB: Database was not shutdown normally!
> 170526 13:48:01 [Note] InnoDB: Starting crash recovery. 170526
> 13:48:01 [Note] InnoDB: Reading tablespace information from the .ibd
> files... 170526 13:48:01 [Note] InnoDB: Restoring possible
> half-written data pages 170526 13:48:01 [Note] InnoDB: from the
> doublewrite buffer... 170526 13:48:06 [ERROR] InnoDB: Tried to read
> 16384 bytes at offset 64208896. Was only able to read 12288.
> 2017-05-26 13:48:06 7f7699b06740 InnoDB: Operating system error
> number 5 in a file operation. InnoDB: Error number 5 means
> 'Input/output error'. InnoDB: Some operating system error numbers are
> described at InnoDB:
> http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
> 170526 13:48:06 [ERROR] InnoDB: File (unknown): 'read' returned OS
> error 105. Cannot continue operation

Sieht aus, als wäre die MySQL-Datei von Akonadi beschädigt, und
außerdem die InnoDB-Log-Datei... Da wird es vermutlich einfacher, das
neu aufzusetzen. Gibt es Backups von deinen Mails?

Die Frage ist eigentlich auch, wie das passieren konnte. Verwendest du
dein Dateisystem mit nobarrier?

> Akonai-Steuerprogram nicht am D-Bus registriert

Das ist nur ein Folgefehler, diesen und nachfolgende Fehler kannst du
vorab ignorieren.

> Das Akonadi-Steuerprogramm ist nicht am D-Bus registriert, was
> normalerweise bedeutet, dass es nicht gestartet wurde oder beim Start
> ein schwerer Fehler aufgetreten ist.
>
>
> Database process exited unexpectedly during initial connection!
> executable: "/usr/sbin/mysqld"
> arguments:
> ("--defaults-file=/home/sebastian/.local/share/akonadi/mysql.conf",
> "--datadir=/home/sebastian/.local/share/akonadi/db_data/",
> "--socket=/tmp/akonadi-sebastian.P5dJCT/mysql.socket") stdout: ""
> stderr: "170526 13:48:01 [Note] /usr/sbin/mysqld (mysqld
> 10.0.30-MariaDB) starting as process 31402 ... " exit code: 1 process
> error: "Process operation timed out" "[
> 0: akonadiserver(_Z11akBacktracev+0x4b) [0x463a6b]
> 1: akonadiserver() [0x463cf2]
> 2: /lib64/libc.so.6(+0x331f0) [0x7f4ed4fae1f0]
> 3: /lib64/libc.so.6(gsignal+0x37) [0x7f4ed4fae167]
> 4: /lib64/libc.so.6(abort+0x16a) [0x7f4ed4faf5ea]
> 5: /usr/lib64/qt4/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x8d)
> [0x7f4ed68ae18d] 6:
> akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0xad) [0x465bad]
> 7: /usr/lib64/qt4/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0x9f)
> [0x7f4ed6954b9f] 8: /usr/lib64/qt4/libQtCore.so.4(+0x125cb5)
> [0x7f4ed6962cb5]
> 9: /usr/lib64/qt4/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x31)
> [0x7f4ed696c9f1] 10: akonadiserver(_ZN6QDebugD1Ev+0x48) [0x45e7c8]
> 11:
> akonadiserver(_ZN7Akonadi6Server13DbConfigMysql19startInternalServerEv+0x1ecb)
> [0x4d53ab] 12:
> akonadiserver(_ZN7Akonadi6Server13AkonadiServer20startDatabaseProcessEv+0xff)
> [0x46681f] 13:
> akonadiserver(_ZN7Akonadi6Server13AkonadiServer4initEv+0xb8)
> [0x468ed8] 14: akonadiserver() [0x536719]
> 15: /usr/lib64/qt4/libQtCore.so.4(_ZN7QObject5eventEP6QEvent+0x1d1)
> [0x7f4ed69e9871]
> 16: /usr/lib64/qt4/libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x8c)
> [0x7f4ed69cf0ac]
> 17: /usr/lib64/qt4/libQtCore.so.4(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x365)
> [0x7f4ed69d2625] 18: /usr/lib64/qt4/libQtCore.so.4(+0x1c343e)
> [0x7f4ed6a0043e]
> 19: /usr/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x244)
> [0x7f4ed4678384] 20: /usr/lib64/libglib-2.0.so.0(+0x4c665)
> [0x7f4ed4678665]
> 21: /usr/lib64/libglib-2.0.so.0(g_main_context_iteration+0x2c)
> [0x7f4ed467872c]
> 22: /usr/lib64/qt4/libQtCore.so.4(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x7e)
> [0x7f4ed6a005be]
> 23: /usr/lib64/qt4/libQtCore.so.4(_ZN10QEventLoop13processEventsE6QFlagsINS_17ProcessEventsFlagEE+0x41)
> [0x7f4ed69cd821]
> 24: /usr/lib64/qt4/libQtCore.so.4(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x1b5)
> [0x7f4ed69cdbd5]
> 25: /usr/lib64/qt4/libQtCore.so.4(_ZN16QCoreApplication4execEv+0x99)
> [0x7f4ed69d3799] 26: akonadiserver(main+0x1e5) [0x45dbe5]
> 27: /lib64/libc.so.6(__libc_start_main+0xf0) [0x7f4ed4f9b790] 28:
> akonadiserver(_start+0x29) [0x45e509] ] "
>
> Gruß
> Sebastian



--
Regards,
Kai

Replies to list-only preferred.



Reply | Threaded
Open this post in threaded view
|

Re: Akonadi

Sven Eden
Hallo allerseits.

> > Akonadi startet hier nicht richtig. Folgende Fehlermeldungen erhalte
> > ich beim Start von Kontact.
> > 170526 13:48:01 [Note] InnoDB: Database was not shutdown normally!
> > 170526 13:48:01 [Note] InnoDB: Starting crash recovery. 170526
> > 13:48:01 [Note] InnoDB: Reading tablespace information from the .ibd
> > files... 170526 13:48:01 [Note] InnoDB: Restoring possible
> > half-written data pages 170526 13:48:01 [Note] InnoDB: from the
> > doublewrite buffer... 170526 13:48:06 [ERROR] InnoDB: Tried to read
> > 16384 bytes at offset 64208896. Was only able to read 12288.
> > 2017-05-26 13:48:06 7f7699b06740 InnoDB: Operating system error
> > number 5 in a file operation. InnoDB: Error number 5 means
> > 'Input/output error'. InnoDB: Some operating system error numbers are
> > described at InnoDB:
> > http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
> > 170526 13:48:06 [ERROR] InnoDB: File (unknown): 'read' returned OS
> > error 105. Cannot continue operation
Wieso wurde denn mysql nicht richtig beendet? Stromausfall oder so?

Naja, die Innodb ist hin.

> Sieht aus, als wäre die MySQL-Datei von Akonadi beschädigt, und
> außerdem die InnoDB-Log-Datei... Da wird es vermutlich einfacher, das
> neu aufzusetzen. Gibt es Backups von deinen Mails?

Alle Mails sind entweder auf dem Server oder dem Dateisystem. Die Datenbank
von Akonadi ist nur für die Organisation und Metadatensuche.

>
> Die Frage ist eigentlich auch, wie das passieren konnte. Verwendest du
> dein Dateisystem mit nobarrier?

"InnoDB: Database was not shutdown normally!" - Und das mitten im
Schreibprozess. Die InnoDB ist *eigentlich* sehr robust.


Gruß

Sven

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Akonadi

Kai Krakow
Am Sat, 27 May 2017 09:18:43 +0200
schrieb Sven Eden <[hidden email]>:

> Hallo allerseits.
>
> > > Akonadi startet hier nicht richtig. Folgende Fehlermeldungen
> > > erhalte ich beim Start von Kontact.
> > > 170526 13:48:01 [Note] InnoDB: Database was not shutdown normally!
> > > 170526 13:48:01 [Note] InnoDB: Starting crash recovery. 170526
> > > 13:48:01 [Note] InnoDB: Reading tablespace information from
> > > the .ibd files... 170526 13:48:01 [Note] InnoDB: Restoring
> > > possible half-written data pages 170526 13:48:01 [Note] InnoDB:
> > > from the doublewrite buffer... 170526 13:48:06 [ERROR] InnoDB:
> > > Tried to read 16384 bytes at offset 64208896. Was only able to
> > > read 12288. 2017-05-26 13:48:06 7f7699b06740 InnoDB: Operating
> > > system error number 5 in a file operation. InnoDB: Error number 5
> > > means 'Input/output error'. InnoDB: Some operating system error
> > > numbers are described at InnoDB:
> > > http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
> > > 170526 13:48:06 [ERROR] InnoDB: File (unknown): 'read' returned OS
> > > error 105. Cannot continue operation  
>
> Wieso wurde denn mysql nicht richtig beendet? Stromausfall oder so?
>
> Naja, die Innodb ist hin.
Richtig...


> > Sieht aus, als wäre die MySQL-Datei von Akonadi beschädigt, und
> > außerdem die InnoDB-Log-Datei... Da wird es vermutlich einfacher,
> > das neu aufzusetzen. Gibt es Backups von deinen Mails?  
>
> Alle Mails sind entweder auf dem Server oder dem Dateisystem. Die
> Datenbank von Akonadi ist nur für die Organisation und Metadatensuche.

Werden nicht sehr kleine Objekte direkt in der Datenbank gespeichert
und nicht extern? Die wären dann doch auch weg?


> > Die Frage ist eigentlich auch, wie das passieren konnte. Verwendest
> > du dein Dateisystem mit nobarrier?  
>
> "InnoDB: Database was not shutdown normally!" - Und das mitten im
> Schreibprozess. Die InnoDB ist *eigentlich* sehr robust.

Ja, eigentlich... Wenn man allerdings die Ordering-Garantien des
Dateisystems abschaltet, geht die beim Absturz/Reset/Stromausfall nun
mal kaputt, zumindest wenn gerade darin geschrieben wird.
HDD-Schreibcache und nobarrier können da beide sehr böse Fallen werden,
die aber in fast jedem einfachen Tuning-Tutorial immer wieder erwähnt
werden. InnoDB muss sich auf den unterliegenden Storage-Stack verlassen
können, sonst funktioniert es nicht.


--
Regards,
Kai

Replies to list-only preferred.

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Akonadi

Sven Eden
Am Samstag, 27. Mai 2017, 10:18:40 CEST schrieb Kai Krakow:
> > Alle Mails sind entweder auf dem Server oder dem Dateisystem. Die
> > Datenbank von Akonadi ist nur für die Organisation und Metadatensuche.
>
> Werden nicht sehr kleine Objekte direkt in der Datenbank gespeichert
> und nicht extern? Die wären dann doch auch weg?

Ja, stimmt. Bis zu 4096 Bytes Größe. :-/

Das sind auch gerne mal Adress- oder Kalendereinträge. E-Mails kann man ja
erneut herunterladen.

Aber was hilfts? Die InnoDB ist futsch... :-(

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Akonadi

Kai Krakow
Am Sat, 27 May 2017 10:58:30 +0200
schrieb Sven Eden <[hidden email]>:

> Am Samstag, 27. Mai 2017, 10:18:40 CEST schrieb Kai Krakow:
> > > Alle Mails sind entweder auf dem Server oder dem Dateisystem. Die
> > > Datenbank von Akonadi ist nur für die Organisation und
> > > Metadatensuche.  
> >
> > Werden nicht sehr kleine Objekte direkt in der Datenbank gespeichert
> > und nicht extern? Die wären dann doch auch weg?  
>
> Ja, stimmt. Bis zu 4096 Bytes Größe. :-/
>
> Das sind auch gerne mal Adress- oder Kalendereinträge. E-Mails kann
> man ja erneut herunterladen.
Per POP3 geholte Mails sind normalerweise nicht mehr auf einem Server...

> Aber was hilfts? Die InnoDB ist futsch... :-(

Legt Akonadi nicht von selbst regelmäßig Backups an als ZIP oder so?
Ich meine das mal irgendwann gesehen zu haben, finde das aktuell aber
nicht mehr wieder.

Aber ich finde aktuell nicht mal Akonadi in den System Settings oder
dem Tray. Was fehlt mir?


--
Regards,
Kai

Replies to list-only preferred.

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Akonadi

Sven Eden
Am Samstag, 27. Mai 2017, 16:13:38 CEST schrieb Kai Krakow:
> Per POP3 geholte Mails sind normalerweise nicht mehr auf einem Server...

Alles eine Frage der Einstellungen. Ich hatte, vor dem Umstieg auf IMAP,
meinen GMX-Agenen so eingestellt, das bis zu 980MB auf dem Server verbleiben
sollen.
Ich kann mich aber beim besten Willen nicht daran erinnern, was der Standard
war. Alles herunterladen, und nichts auf dem Server belassen, oder?

>
> > Aber was hilfts? Die InnoDB ist futsch... :-(
>
> Legt Akonadi nicht von selbst regelmäßig Backups an als ZIP oder so?
> Ich meine das mal irgendwann gesehen zu haben, finde das aktuell aber
> nicht mehr wieder.

Nicht, dass ich wüsste...

>
> Aber ich finde aktuell nicht mal Akonadi in den System Settings oder
> dem Tray. Was fehlt mir?

Wir User sind nicht fähig Akonadi per GUI zu konfigurieren, also gibt es nur
noch
A) ~/.config/akonadi/akonadiserverrc
B) ~/.config/akonadi_maildir_resource_0rc und ...
C) /usr/bin/akonadiconsole (<-- HA, doch GUI)

Zu B) : Hierin steht der Pfad zum Lokalen Ordner. Alle Mails darin finden sich
hier im Dateisystem wieder.

Weiterhin gibt es noch
~/.config/akonadi_imap_resource_*rc für IMAP, und sicherlich eine Entsprechung
für POP3. Zumindes in den IMAP-Resourcen steht aber leider nicht drin, wo die
Mails lokal gespeichert werden.
Allerdings tippe hier ganz stark auf
~/.local/share/akonadi/file_db_data

Letztendlich sind alle Daten bis 4096 Bytes weg, sofern sie nicht erneut vom
Server heruntergeladen werden können, wenn man die Datenbank löscht. Alles
Andere ist im Dateisystem gespeichert. Ob das nach dem Löschen der Datenbank
auch alles brav wieder indiziert wird, weiß ich leider nicht.

Gruß

Sven

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Akonadi

Kai Krakow
Am Wed, 31 May 2017 09:01:35 +0200
schrieb Sven Eden <[hidden email]>:

> Am Samstag, 27. Mai 2017, 16:13:38 CEST schrieb Kai Krakow:
> > Per POP3 geholte Mails sind normalerweise nicht mehr auf einem
> > Server...  
>
> Alles eine Frage der Einstellungen. Ich hatte, vor dem Umstieg auf
> IMAP, meinen GMX-Agenen so eingestellt, das bis zu 980MB auf dem
> Server verbleiben sollen.
> Ich kann mich aber beim besten Willen nicht daran erinnern, was der
> Standard war. Alles herunterladen, und nichts auf dem Server
> belassen, oder?
>
> >  
> > > Aber was hilfts? Die InnoDB ist futsch... :-(  
> >
> > Legt Akonadi nicht von selbst regelmäßig Backups an als ZIP oder so?
> > Ich meine das mal irgendwann gesehen zu haben, finde das aktuell
> > aber nicht mehr wieder.  
>
> Nicht, dass ich wüsste...
>
> >
> > Aber ich finde aktuell nicht mal Akonadi in den System Settings oder
> > dem Tray. Was fehlt mir?  
>
> Wir User sind nicht fähig Akonadi per GUI zu konfigurieren, also gibt
> es nur noch
> A) ~/.config/akonadi/akonadiserverrc
> B) ~/.config/akonadi_maildir_resource_0rc und ...
> C) /usr/bin/akonadiconsole (<-- HA, doch GUI)
Ganz ehrlich: Ich kann's verstehen, wirkten diese Dialoge doch eher wie
Entwickler-Werkzeuge als Enduser-Dialoge. Wahrscheinlich waren Sie auch
nie was anderes...

Zu C) Stimmt, ich hatte die Debug-Console ein wenig vergessen, hier
finden sich sogar die Einstellungsdialoge wieder... Auf dem "Agents"
Reiter.

> Zu B) : Hierin steht der Pfad zum Lokalen Ordner. Alle Mails darin
> finden sich hier im Dateisystem wieder.
>
> Weiterhin gibt es noch
> ~/.config/akonadi_imap_resource_*rc für IMAP, und sicherlich eine
> Entsprechung für POP3. Zumindes in den IMAP-Resourcen steht aber
> leider nicht drin, wo die Mails lokal gespeichert werden.
> Allerdings tippe hier ganz stark auf
> ~/.local/share/akonadi/file_db_data
>
> Letztendlich sind alle Daten bis 4096 Bytes weg, sofern sie nicht
> erneut vom Server heruntergeladen werden können, wenn man die
> Datenbank löscht. Alles Andere ist im Dateisystem gespeichert. Ob das
> nach dem Löschen der Datenbank auch alles brav wieder indiziert wird,
> weiß ich leider nicht.
Bei meinem letzten Crash wurden die alle nie wieder korrekt indiziert,
die waren zwar irgendwie da aber irgendwie auch nicht. Bei einem Check
wurde dann alles nach lost+found verschoben und Akonadi konnte nichts
mehr damit anfangen, weil die Meta-Infos fehlen, die beim Abruf oder
Sync angelegt werden.

Das ist inzwischen aber Jahre her, Akonadi hat sich seitdem verändert
und verbessert - ein bisschen bezweifle ich aber, dass das je wieder
indiziert werden kann, da einfach die Meta-Infos aus der DB fehlen. Ich
hab mal in den Code geschaut, und Akonadi scheint ziemlich essentiell
darauf angewiesen zu sein und kann mit den Objekten sonst nichts
anfangen und verbannt die nach lost+found. Von da aus könnte ich die
zwar mit etwas Script-Fu in ein Maildir verfrachten und dann wieder
importieren... Schön und zuverlässig geht allerdings anders. Zumal auch
jegliche Info verloren geht, in welche Ordner sich die Objekte verteilt
hatten.

Regelmäßige Backups helfen und tun nicht wirklich weh. Wenn
Speicherplatz ein teures Gut ist, kann ich Borgbackup empfehlen: Sehr
schnell und extrem speichereffizient. Sichert täglich mein System (2TB,
viele Millionen Dateien) innerhalb von 10-15 Minuten, und bereits knapp
ein Jahr Backup passen auf eine 3TB Platte (ich sichere also alles und
behalte es auch täglich, mit Ausdünnung nach einigen Wochen).


--
Regards,
Kai

Replies to list-only preferred.

attachment0 (201 bytes) Download Attachment