https://bugs.kde.org/show_bug.cgi?id=524392
--- Comment #3 from Wehrwolfmann <[email protected]> --- Same class of failure as bug 524048 (drkonqi's coredump launcher), and I went through the plasma-workspace code to see whether the session could be blamed. It can't, so here is what I found - hopefully it saves someone the same walk. Plasma does clean the stale variables, and it has since 2022. `isSessionVariable()` (startkde/startplasma.cpp:131) covers DISPLAY, XAUTHORITY, WAYLAND_DISPLAY, WAYLAND_SOCKET and XDG_*, and they are unset from the systemd user manager before anything else is started (:505-534, added in !1420 for bug 449326). I checked /proc on a live session: by the time Plasma is up, the manager environment really is clean. So "log out and back into Wayland" does not explain this one away. Three things still deliver a dead display to a process: 1. A unit reads the manager environment once, when it starts. kde-baloo.service is WantedBy=graphical-session.target, and Cinnamon brings that target up too. The baloo_file started under Cinnamon keeps its own copy of DISPLAY=:0 and spawns baloo_file_extractor with it. Cleaning the manager environment afterwards cannot reach a process that is already running - which is exactly the reported sequence. 2. Logging out does not clean anything. cleanupPlasmaEnvironment (:471-498) passes unset=every current key and set=the whole oldSystemdEnvironment in one call (:493), and set wins, so the environment is simply assigned back to what it was; it also runs before the login-time drop. The stale set is handed to whichever desktop comes next. 3. The same variables also live in D-Bus' activation environment, and the bus has no unset call at all - UpdateActivationEnvironment can only add. How much that matters depends on the implementation: I checked here, and dbus-broker forwards UpdateActivationEnvironment straight into systemd, so `systemctl --user unset-environment` does reach it. On a classic dbus-daemon it does not - I confirmed on a private test bus that a variable set only through UpdateActivationEnvironment reaches activated services and cannot be removed. Fabian Vogt described both remaining scenarios in bug 449326 comment 7 back in 2022 ("an improperly terminated Plasma session or just after switching from a different DE"), and the fix that landed covered login only. I can't reproduce your full sequence here (I don't run a second desktop), but the part that matters reproduces on demand without any of it. On Plasma 6.7.4, KF 6.29: $ env DISPLAY=:9 WAYLAND_DISPLAY=wayland-9 /usr/lib/kf6/baloo_file_extractor </dev/null Failed to create wl_display (No such file or directory) qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" qt.qpa.xcb: could not connect to display :9 This application failed to start because no Qt platform plugin could be initialized. $ echo $? 134 134 is SIGABRT, from qFatal() inside the QGuiApplication constructor - the same abort as in your backtrace, before the extractor has looked at a single file. With a usable display the same command exits 0. Worth noting that only one of the two needs to be alive: with a stale DISPLAY but a working WAYLAND_DISPLAY it starts normally, which is why this only bites after a desktop that leaves both behind. Which leaves the decision with the process itself. baloo_file_extractor is a headless indexer - it has no window and no reason to die because DISPLAY points at nothing. Either QCoreApplication where the extractors allow it, or checking that the display we were handed exists and degrading to QT_QPA_PLATFORM=offscreen before QGuiApplication is constructed. The same approach for drkonqi's launcher is in plasma/drkonqi!421 if it is useful as a reference. -- You are receiving this mail because: You are watching all bug changes.
