"Akonadi-Server wurde unerwartet beendet"

[Isegrimm666]

Guten Morgen ...

Ich habe eben ein FU durchgeführt und erhalte beim Neustart die Meldung, dass der Akonadi-Server unerwartet beendet wurde. (s. Anl.)

Klicke ich auf "Fehlerbericht senden" passiert nichts, Die Meldung kommt in Abständen erneut.

Das System läuft normal ... bis auf die Akonadi-Meldung geschieht nichts. Obwohl ich den Haken bei "Anwendung neu starten" entfernt habe, erscheint die Meldung immer wieder.

Details:

Code Select Expand

Starting debugger gdb -nw -n -batch --init-eval-command=set debuginfod enabled on -x /tmp/drkonqi.hYUcdX -x /tmp/drkonqi.BNTVMg -p 105788 /usr/bin/akonadiserver
[New LWP 105789]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/x86_64-linux-gnu/libthread_db.so.1".
__syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56

warning: 56 ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S: No such file or directory
Traceback (most recent call last):
  File "/usr/share/drkonqi/gdb/python/gdb_preamble/preamble.py", line 608, in print_preamble
    print_preamble_internal()
    ~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/share/drkonqi/gdb/python/gdb_preamble/preamble.py", line 582, in print_preamble_internal
    resolve_modules()
    ~~~~~~~~~~~~~~~^^
  File "/usr/share/drkonqi/gdb/python/gdb_preamble/preamble.py", line 565, in resolve_modules
    raise RuntimeError("No corefile found. Cannot resolve modules.")
RuntimeError: No corefile found. Cannot resolve modules.
No corefile found. Cannot resolve modules.
A debugging session is active.

Inferior 1 [process 105788] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 105788) detached]
Debugging ended with exit code '1' and exit status 'NormalExit'


[Isegrimm666]

Oki .... teste ich nachher mal, wenn ich wieder zu Hause bin.

[Teriarch]

Schuld ist ein upgrade von mariadb-server-core von Version 11.8.5-4 auf Version 11.8.6-1.
Darin enthalten ist u.a. der server "/usr/sbin/mariadbd", der einen Segfault verursacht, sobald er
vom akonadiserver "/usr/bin/akonadiserver" als link "/usr/sbin/mysqld -> mariadbd" gestartet wird.
Dieser crash wird in Folge von drkonqi bemerkt, der wiederum erfolglos versucht, den erwähnten
Report zu generieren.

Abhilfe schafft vorübergehend ein Überschreiben von "/usr/sbin/mariadbd" durch die alte Version,
die Du sicher noch im Verzeichnis  /var/cache/apt/archives finden kannst. Pack' einfach mit

$ cd /tmp
$ dpkg -x /var/cache/apt/archives/mariadb-server-core_1%3a11.8.5-4_amd64.deb .

den alten server aus und überschreibe den neuen mit

$ sudo cp /tmp/usr/sbin/mariadbd  /usr/sbin/mariadbd

bis das Problem von den Entwicklern erkannt und gefixt ist.

[charlyheinz]

Hallo
Hatte gestern das gleiche Problem auf einem meiner Rechner und es gerade behoben.
Nachdem ich die Installationen beider Systeme verglichen habe hat sich herausgestellt das der eine Rechner ohne Probleme SQLite, der mit Problemen mySQL als DB- Server verwendet. Habe den problematischen Rechner auf SQLite umgestellt und anschließend eine Neu- Konfiguration von Akonadi angestoßen.
Bin nach diesem Link vorgegangen (Siehe Abschnitt zurücksetzen): https://wiki.ubuntuusers.de/Akonadi/#Dateien-von-Akonadi
Jetzt bleibt Akonadi still und meine Kalender werden angezeigt.
Ob man unbedingt den SQL-Server umstellen muss weiß ich nicht 100%ig. Ich würde erst einmal wie im Link beschrieben Akonadi zurücksetzen.

[Teriarch]

Hab' ich versucht. Der vom akonadiserver gestartete /usr/sbin/mysqld aka /usr/sbin/mariadbd meldet sich mit:

/usr/sbin/mysqld --defaults-file=$HOME/.local/share/akonadi/mysql.conf --datadir=$HOME/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket --pid-file=/run/user/1000/akonadi/mysql.pid

Folglich sind $HOME/.local/share/akonadi/mysql.conf sowie $HOME/.local/share/akonadi/db_data betroffen. mysql.conf enthält:

Code Select Expand


[mysqld]
character_set_server=utf8
collation_server=utf8_general_ci
default_storage_engine=innodb
innodb_buffer_pool_size=128M
innodb_file_per_table=1
innodb_flush_log_at_trx_commit=2
innodb_log_buffer_size=1M
innodb_log_file_size=64M
log_error=mysql.err
loose_log_warnings=2
lower_case_table_names=1
max_allowed_packet=32M
max_connections=256
loose_query_cache_size=0
loose_query_cache_type=0
skip_grant_tables
skip_networking
table_open_cache=200
thread_cache_size=3
wait_timeout=31536000
key_buffer_size=16K
secure_file_priv=
[client]
default-character-set=utf8


also nichts, was einen Absturz rechtfertigt. db_data hatte ich umbenannt (gesichert) und ein leeres Verzeichnis gleichen Namens
angelegt. Nach dem restart des akonadiservers (mit dem aktuellen mysql) wurde dieses Verzeichnis zunächst mit default Einträgen befüllt, und danach stürzte mysql in gewohnter Weise wieder ab (dmesg):

one_connection[5407]: segfault at 0 ip 0000000000000000 sp 00007f27483adea8 error 14 likely on CPU 6 (core 2, socket 0)
Code: Unable to access opcode bytes at 0xffffffffffffffd6.

Interessanter Weise startet mariadb.service (ohne akonadi) fehlerfrei. Meine interims Lösung:

/usr/sbin/mariadbd -> /usr/sbin/mariadbd.new
/usr/sbin/mysqld -> /usr/sbin/mariadbd.old

Damit scheint es zunächst zu laufen. In jedem Fall ist der neue mariadbd buggy und sollte ersetzt werden.

[charlyheinz]

Wie geschrieben habe ich zusätzlich mySQL mit SQLite ausgetauscht:

akonadi-backend-mysql entfernt
default-mysql-client-core entfernt
default-mysql-server-core entfernt

dabei wird
mariadb-client-core
mariadb-server-core
als Abhängigkeit ebenfalls entfernt.

akonadi-backend-sqlite (Version 4:25.12.1-2)  installiert
qml6-module-org-kde-akonadi (Version 4:25.12.1-2)  installiert

Anschließend habe ich mariadb client / server wieder installiert. Hat hier sauber funktioniert.

[Teriarch]

Kannst Du mir Deinen Output von

$ ps xa|grep akonadi

zeigen? Ich vermute, dass durch die Integration von SQLite der akonadiserver /usr/sbin/mariadbd nicht
mehr startet (vermutlich zeigt der link /usr/sbin/mysqld auf ein anders Program)), und es deshalb zu keinem
Absturz mehr kommt. Das würde sich mit meinem Ansatz vertragen, bei dem  ebenfalls /usr/sbin/mysqld
auf ein anderes Programm (den alten mariadbd) zeigt.

[charlyheinz]

$ ps xa|grep akonadi
   8627 ?        Sl     0:00 /usr/bin/akonadi_control
   8640 ?        Sl     0:00 /usr/bin/akonadiserver
   8652 ?        Sl     0:00 /usr/bin/akonadi_archivemail_agent --identifier akonadi_archivemail_agent
   8653 ?        Sl     0:00 /usr/bin/akonadi_birthdays_resource --identifier akonadi_birthdays_resource
   8654 ?        Sl     0:00 /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_0
   8655 ?        Sl     0:00 /usr/bin/akonadi_followupreminder_agent --identifier akonadi_followupreminder_agent
   8656 ?        Sl     0:00 /usr/bin/akonadi_ical_resource --identifier akonadi_ical_resource_0
   8657 ?        Sl     0:00 /usr/bin/akonadi_ical_resource --identifier akonadi_ical_resource_1
   8658 ?        SNl    0:00 /usr/bin/akonadi_indexing_agent --identifier akonadi_indexing_agent
   8659 ?        Sl     0:00 /usr/bin/akonadi_maildir_resource --identifier akonadi_maildir_resource_0
   8660 ?        Sl     0:00 /usr/bin/akonadi_maildispatcher_agent --identifier akonadi_maildispatcher_agent
   8661 ?        Sl     0:00 /usr/bin/akonadi_mailfilter_agent --identifier akonadi_mailfilter_agent
   8662 ?        Sl     0:00 /usr/bin/akonadi_mailmerge_agent --identifier akonadi_mailmerge_agent
   8663 ?        Sl     0:00 /usr/bin/akonadi_migration_agent --identifier akonadi_migration_agent
   8664 ?        Sl     0:00 /usr/bin/akonadi_newmailnotifier_agent --identifier akonadi_newmailnotifier_agent
   8665 ?        Sl     0:00 /usr/bin/akonadi_sendlater_agent --identifier akonadi_sendlater_agent
   8666 ?        Sl     0:00 /usr/bin/akonadi_unifiedmailbox_agent --identifier akonadi_unifiedmailbox_agent
907791 pts/1    S+     0:00 grep akonadi


Hatte ich ich mit " akonadictl status " auch schon überprüft. Scheint soweit i.O. zu sein.

[charlyheinz]

akonadictl status
Akonadi Control: running
Akonadi Server: running
Akonadi Server Search Support: available (Remote Search)
Available Agent Types: akonadi_archivemail_agent, akonadi_birthdays_resource, akonadi_contacts_resource, akonadi_davgroupware_resource, akonadi_ews_resource, akonadi_ewsmta_resource, akonadi_followupreminder_agent, akonadi_google_resource, akonadi_ical_resource, akonadi_icaldir_resource, akonadi_imap_resource, akonadi_indexing_agent, akonadi_maildir_resource, akonadi_maildispatcher_agent, akonadi_mailfilter_agent, akonadi_mailmerge_agent, akonadi_mbox_resource, akonadi_migration_agent, akonadi_mixedmaildir_resource, akonadi_newmailnotifier_agent, akonadi_openxchange_resource, akonadi_pop3_resource, akonadi_sendlater_agent, akonadi_unifiedmailbox_agent, akonadi_vcard_resource, akonadi_vcarddir_resource

[Teriarch]

Vergleichen wir

>  8640 ?        Sl     0:00 /usr/bin/akonadiserver
>  8652 ?        Sl     0:00 /usr/bin/akonadi_archivemail_agent --identifier akonadi_archivemail_agent

mit

  14330 ?        Sl     0:00 /usr/bin/akonadiserver
  14336 ?        Sl     0:01 /usr/sbin/mysqld --defaults-file=/home/wt/.local/share/akonadi/mysql.conf --datadir=\\
                                       /home/wt/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket\\
                                       --pid-file=/run/user/1000/akonadi/mysql.pid
  14366 ?        Sl     0:00 /usr/bin/akonadi_archivemail_agent --identifier akonadi_archivemail_agent

Die interessante Frage ist, was in Deinem Fall der akonadiserver startet (In meinem Fall offenbar mysqld).
Wir müssen hier tiefer graben:

$ pstree|grep akonadi

        |         |-akonadi_control-+-akonadi_archive---6*[{akonadi_archive}]
        |         |                 |-akonadi_followu---5*[{akonadi_followu}]
        |         |                 |-akonadi_ical_re---2*[{akonadi_ical_re}]
        |         |                 |-akonadi_indexin---2*[{akonadi_indexin}]
        |         |                 |-akonadi_maildir---2*[{akonadi_maildir}]
        |         |                 |-akonadi_maildis---5*[{akonadi_maildis}]
        |         |                 |-akonadi_mailfil---6*[{akonadi_mailfil}]
        |         |                 |-akonadi_mailmer---5*[{akonadi_mailmer}]
        |         |                 |-akonadi_migrati---5*[{akonadi_migrati}]
        |         |                 |-akonadi_newmail---5*[{akonadi_newmail}]
        |         |                 |-akonadi_sendlat---5*[{akonadi_sendlat}]
        |         |                 |-akonadi_unified---5*[{akonadi_unified}]
        |         |                 |-akonadiserver-+-mysqld---13*[{mysqld}]
        |         |                 |               `-24*[{akonadiserver}]
        |         |                 `-7*[{akonadi_control}]

Die vorletzte Zeile zeigt, dass in meinem Fall akonadiserver der Vater von mysqld ist. Kannst Du mir
Deinen Output von "$ pstree|grep akonadi" zeigen. Und falls Du "Deinen" <mysqld> gefunden hast,
anschließend den Output von

$ ps xa|grep <mysqld>

damit wir sehen, welche Konfigurationsdateien verwendet werden.

[finotti]

Just to clarify: there is a bug in akonadi-sever, and we should wait for a fix before upgrading, correct?

[pit]

Wie geschrieben habe ich zusätzlich mySQL mit SQLite ausgetauscht

Bin gestern in die gleiche Falle gelaufen und dann in Sachen Akonadi auf SQLite gewechselt. Funktioniert nun wieder wunschgemäß.

[Teriarch]

@finotti

> Just to clarify: there is a bug in akonadi-sever, and we should wait for a fix before upgrading, correct?

There is no bug in akonadi-sever, there is a bug in the latest version of mariadb-server-core, and we are
dancing around the acconadiserver's usage of /usr/sbin/mysqld linked to /usr/sbin/mariadbd (which contains the bug).
You can either use the previous /usr/sbin/mariadbd (my solution) or install sqlite (akonadi-backend-sqlite, charlyheinz' solution).
The choice is yours until the issue is settled by the developers.

[finotti]

@finotti

> Just to clarify: there is a bug in akonadi-sever, and we should wait for a fix before upgrading, correct?

There is no bug in akonadi-sever, there is a bug in the latest version of mariadb-server-core, and we are
dancing around the acconadiserver's usage of /usr/sbin/mysqld linked to /usr/sbin/mariadbd (which contains the bug).
You can either use the previous /usr/sbin/mariadbd (my solution) or install sqlite (akonadi-backend-sqlite, charlyheinz' solution).
The choice is yours until the issue is settled by the developers.

Thank you for the clarification.  I tried charlyheinz solution in my laptop, and it indeed worked, but I might wait for a fix before dist-upgrading my desktop.

[Isegrimm666]

Guten Morgen ...

Ich habe eben ein full-upgrade durchgeführt.

Nach einem Neustart ploppte die Fehlermeldung des Akonadi-Servers nicht mehr auf.

Ich denke, es hat sich damit wohl erledigt.

Update (04:04h):
Leider doch nicht.