ich habe auf meinem System festgestellt, dass die Art, wie der opsiclientd die grafische Session unter Linux ermittelt leider unter Wayland-only Systemen dazu führt, dass Updates und Produktaktionen gar nicht mehr abgearbeitet werden und erst eine Neuanmeldung bzw. Neustart des Systems dieses Problem (temporär) heilt. Das betroffene System ist ein AlmaLinux 10.2 auf welchem es kein X11 mehr gibt, sondern nur noch Wayland.
Das Problem:
Manchmal kommt es vor, dass plötzlich auf einem Client eine Produktinstallation einfach nicht mehr läuft, obwohl man diese immer wieder über den opsi-configed auslöst. Ich sehe dann, wie das Paket zunächst gecacht wird, die Installation dann aber nicht anläuft. Die Events sind so konfiguriert, dass die Produktaktionen sofort laufen sollen, ohne vorherigen Neustart. Ich habe mir dann mal das Log vom opsiclientd angesehen und finde darin dann immer diese Zeilen, wenn dieses Problem auftritt:
/var/log/opsi-client-agent/opsiclientd.log
Code: Alles auswählen
[5] [2026-09-08 15:17:31.259] [event processing sync_completed{cache_ready_user_logged_in}] ============= EventProcessingThread for occurrcence of event 'sync_completed{cache_ready_user_logged_in}' started ============= (EventProcessing.py:1900)
[5] [2026-09-08 15:17:31.265] [event processing sync_completed{cache_ready_user_logged_in}] Block login now set to 'False' (Opsiclientd.py:384)
[5] [2026-09-08 15:17:31.265] [event processing sync_completed{cache_ready_user_logged_in}] Starting notification server (EventProcessing.py:202)
[6] [2026-09-08 15:17:31.271] [notification server ] Notification server serving on ('127.0.0.1', 44000) (notification_server.py:286)
[5] [2026-09-08 15:17:31.271] [notification server ] Notification server started (listening on port 44000) (EventProcessing.py:231)
[5] [2026-09-08 15:17:31.274] [event processing sync_completed{cache_ready_user_logged_in}] Action processor name 'opsi-script', version '4.12.21.0' (EventProcessing.py:368)
[5] [2026-09-08 15:17:31.275] [event processing sync_completed{cache_ready_user_logged_in}] Waiting for connection to config server (EventProcessing.py:1963)
[6] [2026-09-08 15:17:31.275] [event processing sync_completed{cache_ready_user_logged_in}] JSON-RPC request to https://***************:4447: id='81d7627d-8e86-4e4c-b763-6265ac682b8e', method=productOnClient_getObjects, Content-Type=application/msgpack, Content-Encoding=lz4, timeout=300.0 (_service_client.py:1665)
[6] [2026-09-08 15:17:31.307] [event processing sync_completed{cache_ready_user_logged_in}] Got response status=200, id='81d7627d-8e86-4e4c-b763-6265ac682b8e', method=productOnClient_getObjects, Content-Type=application/msgpack, Content-Encoding=, duration=0.032s (_service_client.py:1689)
[5] [2026-09-08 15:17:31.308] [event processing sync_completed{cache_ready_user_logged_in}] [ 1] product *****: setup (EventProcessing.py:876)
[6] [2026-09-08 15:17:31.308] [event processing sync_completed{cache_ready_user_logged_in}] JSON-RPC request to https://***************:4447: id='33fb0b78-3958-4c59-92ea-4ba73dbf48cc', method=productOnDepot_getObjects, Content-Type=application/msgpack, Content-Encoding=lz4, timeout=300.0 (_service_client.py:1665)
[6] [2026-09-08 15:17:31.329] [event processing sync_completed{cache_ready_user_logged_in}] Got response status=200, id='33fb0b78-3958-4c59-92ea-4ba73dbf48cc', method=productOnDepot_getObjects, Content-Type=application/msgpack, Content-Encoding=, duration=0.021s (_service_client.py:1689)
[5] [2026-09-08 15:17:31.329] [event processing sync_completed{cache_ready_user_logged_in}] Start processing action requests (EventProcessing.py:921)
[6] [2026-09-08 15:17:31.329] [event processing sync_completed{cache_ready_user_logged_in}] JSON-RPC request to https://***************:4447: id='c3ad0801-d20e-4dc8-bd94-095ed291c351', method=productOnDepot_getObjects, Content-Type=application/msgpack, Content-Encoding=lz4, timeout=300.0 (_service_client.py:1665)
[6] [2026-09-08 15:17:31.361] [event processing sync_completed{cache_ready_user_logged_in}] Got response status=200, id='c3ad0801-d20e-4dc8-bd94-095ed291c351', method=productOnDepot_getObjects, Content-Type=application/msgpack, Content-Encoding=, duration=0.031s (_service_client.py:1689)
[6] [2026-09-08 15:17:31.361] [event processing sync_completed{cache_ready_user_logged_in}] JSON-RPC request to https://***************:4447: id='8fdcb8a4-fb18-453e-9f05-6824fcdbea50', method=product_getObjects, Content-Type=application/msgpack, Content-Encoding=lz4, timeout=300.0 (_service_client.py:1665)
[6] [2026-09-08 15:17:31.385] [event processing sync_completed{cache_ready_user_logged_in}] Got response status=200, id='8fdcb8a4-fb18-453e-9f05-6824fcdbea50', method=product_getObjects, Content-Type=application/msgpack, Content-Encoding=, duration=0.024s (_service_client.py:1689)
[6] [2026-09-08 15:17:31.385] [event processing sync_completed{cache_ready_user_logged_in}] Notifying user of actions to process <opsiclientd.Events.SyncCompleted.SyncCompletedEvent object at 0x7f06d0033e10> (['*****']) (EventProcessing.py:1313)
[3] [2026-09-08 15:17:31.414] [event processing sync_completed{cache_ready_user_logged_in}] Failed to process product action requests: (EventProcessing.py:1021)
Traceback (most recent call last):
File "opsiclientd/EventProcessing.py", line 971, in processProductActionRequests
File "opsiclientd/EventProcessing.py", line 1346, in processActionWarningTime
File "opsiclientd/EventProcessing.py", line 323, in startNotifierApplication
File "opsiclientd/EventProcessing.py", line 189, in getSessionId
File "opsiclientd/Opsiclientd.py", line 857, in getSessionId
File "opsi/system/session/_linux.py", line 54, in get_display_sessions
AssertionError
[6] [2026-09-08 15:17:31.508] [ ] JSON-RPC request to https://***************:4447: id='13a7c3d6-9230-49fe-9101-939b2df5894d', method=depot_releaseTransferSlot, Content-Type=application/msgpack, Content-Encoding=lz4, timeout=300.0 (_service_client.py:1665)
[6] [2026-09-08 15:17:31.539] [ ] Got response status=200, id='13a7c3d6-9230-49fe-9101-939b2df5894d', method=depot_releaseTransferSlot, Content-Type=application/msgpack, Content-Encoding=, duration=0.031s (_service_client.py:1689)
[5] [2026-09-08 15:17:34.421] [event processing sync_completed{cache_ready_user_logged_in}] Block login now set to 'False' (Opsiclientd.py:384)
[6] [2026-09-08 15:17:34.422] [ ] Stopping notification server (EventProcessing.py:238)
[5] [2026-09-08 15:17:34.422] [event processing sync_completed{cache_ready_user_logged_in}] Block login now set to 'False' (Opsiclientd.py:384)
[5] [2026-09-08 15:17:34.423] [event processing sync_completed{cache_ready_user_logged_in}] ============= EventProcessingThread for event 'sync_completed{cache_ready_user_logged_in}' ended ============= (EventProcessing.py:2073)
Hier sieht man, dass es offenbar zu einem AssertionError kommt beim Versuch, die Notifier-Anwendung zu starten. Ich habe mir den betreffenden Code und die Funktion get_display_sessions einmal genauer angesehen. Ganz offensichtlich dient die Funktion dazu, zu ermitteln, welche aktuellen grafischen Sessions auf dem System laufen, welche für die Anzeige des Notifiers genommen werden können. Ob es hierfür nicht einen besseren Weg gäbe, als alle Prozesse durchzugehen und die Umgebungsvariablen zu prüfen, mag ich gerade nicht beurteilen, aber ich sehe auf jeden Fall das Problem in dieser Funktion darin, dass diese ALLE Prozesse durchläuft und mittendrin ein assert ausführt, sobald auch nur bei einem Prozess die Umgebungsvariable WAYLAND_DISPLAY nicht gesetzt ist:
Code: Alles auswählen
session_id = wayland_display if linux_session_type == LinuxDisplaySessionType.WAYLAND else display
assert session_id
Ich habe auf meinem System festgestellt, dass eine solche Situation bspw. nach einem Standby entstehen kann. Warum manche Prozesse hiernach keine WAYLAND_DISPLAY-Variable haben, weiß ich nicht, aber es sollte hier auch irrelevant sein und irgendein Firefox-Prozess, der eine unerwartete Prozessumgebung hat, sollte nicht das opsi Paket-Update, welches ich bei einem Anwender jetzt ausführen will, in den Abgrund reißen.
Leider hilft hier auch keinerlei Konfiguration (bspw. das Setzen von event_notifier_command auf einen leeren Wert), da das leider nicht ausgwertet wird vor der Ermittlung der Display-Sessions. Es hilft auch nicht, den opsiclientd neuzustarten, da dieser ja nicht das Problem ist, sondern die externen Prozesse, die der opsiclientd unnötigerweise in seine Laufzeitprüfung einbezieht und diese können ja nicht einfach terminiert werden.
(M)ein Vorschlag:
Meiner Ansicht nach sollte im Mindesten das assert-Statement an dieser Stell nicht stehen, da es hier keinen Mehrwert schafft. Hilfreich wäre darüber hinaus auch eine Prüfung darauf, ob überhaupt ein Notifier-Kommando konfiguriert ist, bevor der Pfad überhaupt betreten wird (es gibt ja Events, bei denen kein Notifier oder irgendwas angezeigt werden und die Installation still ablaufen soll). So könnte ich wenigstens trotzdem ein Paket auf einen Client pushen und müsste den Nutzern nicht erklären, warum diese ihr System leider erst einmal neustarten müssen.
Kann ich hier kurzfristig irgendetwas machen oder konfigurieren, sodas ich mit der aktuellen Version des opsiclientd dieses Verhalten umschiffen kann?
Danke und viele Grüße