Upgrade of akonadi (24.02.2 -> 24.05.0) 20240531fails to send mail

akonadi queues mail in outbox, but fails to send:

karl@erlangen:~> journalctl --user -b -1 -u app-org.kde.kalendarac@autostart.service --identifier akonadi_maildispatcher_agent
Jun 04 09:08:07 erlangen akonadi_maildispatcher_agent[17602]: org.kde.pim.akonadicore: "QLocalSocket: Remote closed" "/run/user/1000/akonadi/akonadiserver-cmd.socket"
Jun 04 09:08:07 erlangen akonadi_maildispatcher_agent[17602]: org.kde.pim.akonadicore: Akonadi server running without control process!
Jun 04 09:08:07 erlangen akonadi_maildispatcher_agent[17602]: The X11 connection broke (error 1). Did the X11 server die?
karl@erlangen:~> 

Rebooting the machine after upgrading infamous host erlangen to 20240531 didn’t fix the issue. However rebooting a second time made akonadi great again. :smiley:

1 Like

More trouble with akonadi:

roland@burgberg:~> akonadictl start
org.kde.pim.akonadictl: Starting Akonadi Server...
qt.qpa.xcb: could not connect to display 
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: minimal, offscreen, minimalegl, linuxfb, eglfs, xcb, wayland, wayland-egl, vkkhrdisplay, vnc.

Error: akonadi_control was started but didn't register at D-Bus session bus.
Make sure your system is set up correctly!
roland@burgberg:~> 

Checked for xcb-cursor0:

burgberg:~ # zypper se -is xcb-cursor0
Loading repository data...
Reading installed packages...

S | Name           | Type    | Version   | Arch   | Repository
--+----------------+---------+-----------+--------+--------------------
i | libxcb-cursor0 | package | 0.1.5-1.3 | x86_64 | openSUSE-20171205-0
burgberg:~ # 

Any idea?

No issues here on 3 machines. That said, all of the use Postgresql, and Plasma6 on Wayland.
So, to answer your question: no

Thanks for the feedback.

Rebooting host burgberg several times wouldn’t fix akonadi trouble as it did with infamous host erlangen.

Stopped remote administration, removed burgberg’s SSD from its chassis and put it into host i4130. This wouldn’t fix the trouble either.

However I discovered a rescue system I booted into. Performed a dup of rescue from September 2022 without further ado:

burgberg:~ # journalctl --directory /mnt/@/var/log/journal/35b9c02feff44b72a572c5c4423e3344/ -b 37f2054345b54a2f845fa9125ec0b924 -u run-u74 -g 'Pakete|Consumed'
Jun 11 20:24:20 localhost.localdomain zypper[2940]: Installierte Pakete werden gelesen...
Jun 11 20:24:26 localhost.localdomain zypper[2940]: Die folgenden 1992 Pakete werden aktualisiert:
Jun 11 20:24:26 localhost.localdomain zypper[2940]: Die folgenden 7 Pakete werden die Architektur ändern:
Jun 11 20:24:26 localhost.localdomain zypper[2940]: Die folgenden 927 NEUEN Pakete werden installiert:
Jun 11 20:24:26 localhost.localdomain zypper[2940]: Die folgenden 321 Pakete werden GELĂ–SCHT:
Jun 11 20:24:26 localhost.localdomain zypper[2940]: 1992 Pakete werden aktualisiert, 927 neue, 321 zu entfernen, 7 Architekturwechsel.
Jun 11 20:38:24 linux.fritz.box systemd[1]: run-u74.service: Consumed 11min 42.276s CPU time.
burgberg:~ # 

Booted into burgberg again and trouble with akonadi was gone. Never touched burgberg system partition.

This morning I put burgberg back into its chassis where it makes Roland happy again.