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:
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'
Oki .... teste ich nachher mal, wenn ich wieder zu Hause bin.
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.
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 (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.
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:
[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.
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.
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.
$ 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.
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
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.
Just to clarify: there is a bug in akonadi-sever, and we should wait for a fix before upgrading, correct?
Quote from: charlyheinzWie 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äß.
@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.
Quote from: Teriarch on 2026/02/10, 21:11:55
@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.
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.
Hier noch die aktuellen Empfehlungen vom Debian Team:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1127431#70>
Progress is under way:
<https://github.com/MariaDB/server/commit/87309d3d4bb8f48910d05b0ca5ee989bcdd6b053>
Update:
According to
<https://jira.mariadb.org/browse/MDEV-38811>:
> Otto Kekäläinen added a comment - 8 hours ago
> KDE bug report: https://bugs.kde.org/show_bug.cgi?id=515873
> Arch already applied (https://gitlab.archlinux.org/archlinux/packaging/packages/mariadb-lts/-/commit/
> cfdf73694f366e753b23c43983895a27cb3e6b99) Serg's draft fix (https://github.com/MariaDB/server/
> commit/87309d3d4bb8f48910d05b0ca5ee989bcdd6b053)
> and Arch users report it fixed the issue.
> Thus I will upload that commit to Debian now too.
Case closed!
Thank you very much for your efforts.
Der Fix wurde eingearbeitet.
Nach einem full-upgrade läuft akonadi wieder normal.