opsiclientd startet Notifier und Paketaktionen nicht auf Wayland-only Umgebungen → nur Neustart hilft

[arno.nym]

Hallo,

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)

Meine Analyse:

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

Es erschließt sich mir nicht, welchen Mehrwert dieses assert-Statement an dieser Stelle bringen soll. Die Funktion sammelt ohnehin über alle Prozesse hinweg die ermittelten Display Sessions in einem Dictionary und prüft mehrmals auf die Vorbedingung einiger Variablen. Allerdings kann es durchaus den Fall geben, dass ein Prozess auf einem Wayland-System trotzdem nicht die Variable WAYLAND_DISPLAY gesetzt hat, da die Anwendung auch über eine Wayland-X11-Kompatibilitätsschicht dargestellt werden kann. Hier anzunehmen, dass bei einer Wayland-Sitzung auch die WAYLAND-Variable existieren würde und dies dann mit einem assert zu "prüfen", bricht die gesamte Abarbeitung ab und verhindert damit effektiv jedwede Prozessausführung – zumindest bist zum nächsten Neustart.

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

[j.schneider]

Hallo,

ja, da gibt es noch Verbesserungspotenzial.
In dieser neuen Version wurde das Linux-Session-Handling noch einmal grundlegend überarbeitet:

https://opsipackages.43.opsi.org/testin ... 6.1-1.opsi

Wir freuen uns auf Feedback zu der neuen Version!

Grüße
Jan Schneider

[arno.nym]

Hallo Jan,

vielen Dank für die Rückmeldung. Ich teste gerne bei Zeiten mal die von dir verlinkte Version, wenngleich ich sie natürlich noch nicht auf unseren Geräten in der Fläche verteilen könnte.

Ich habe allerdings zwischenzeitlich einen mitauslösenden Faktor bei meinem Problem ermittelt, der die ganze Thematik entschärft:
Es ist nämlich so, dass in unserer Geräteflotte derzeit sowohl AlmaLinux 9 als auch 10 zum Einsatz kommen. Alma 9 hat sowohl noch einen nativen X11 und Wayland drauf. Alma 10 kommt nur noch mit Wayland (und dem damit einhergehenden Xwayland). Auf den Alma 9-Geräten musste ich in der Vergangenheit für einige Anwendungen die Umgebungsvariable GDK_BACKEND=x11 setzen, da diese sonst teilweise nicht richtig gerendert wurden oder sich falsch verhielten. Mir ist nun aufgefallen, dass sich diese Einstellung so auch auf die Alma 10-Geräte fortgepflanzt hat – was an und für sich noch nicht das Problem war. Problematisch wurde es tatsächlich nun durch den Firefox, der nämlich durch die Variable MOZ_ENABLE_WAYLAND=1 das native Wayland-Interface nutzt. In Kombination mit GDK_BACKEND=x11 hat das jetzt aber dafür gesorgt, dass manche Threads des Firefox (irgendwelche Web Component-Prozesse, wie ich sehen konnte) nun aber so liefen, wie ich in meinem ersten Post beschrieben habe: mit Sitzungstyp "wayland", aber ohne gesetzten WAYLAND_DISPLAY.

Ich setze auf meinem System nun GDK_BACKEND=wayland,x11 (somit fallen Prozesse nur auf X11 zurück, wenn das Wayland-Backend aus irgendeinem Grund nicht verfügbar sein soll) und nun benimmt sich der Firefox auch und opsi-script kann seine Arbeit tun.

Ich bin zwar weiterhin überzeugt, dass beim Auffinden verfügbarer grafischer Sitzungen im Event-Processing nicht ein einziger Prozess die ganze Abarbeitung abbrechen sollte, aber so habe ich wenigstens die Ursache für mich – und vielleicht auch Mitlesende – etwas eingegrenzt. Ich freue mich aber auf die aktualisierte Version des Client-Agents.

Viele Grüße
Anton