https://bugs.kde.org/show_bug.cgi?id=481678
--- Comment #1 from Kacper Paczos <[email protected]> --- Still reproduces on Plasma 6.7.4 with Qt 6.11.1, two and a half years later. I ran into this without knowing the report existed. My session had accumulated 43 `xdg-desktop-portal-kde` processes over three days of uptime — around 65 MB RSS each, 1.88 GB of RSS plus swap between them — and the desktop had started stuttering. Every one of them was orphaned in exactly the way you describe: none held a name on the session bus, and the bus that had activated each of them was long gone. What put them there was two `dbus-daemon --session --fork` processes a test script had left behind two days earlier. Anything that starts a private session bus and then touches a portal will do it — a private bus gets the stock service directories, so it activates the real `/usr/libexec/xdg-desktop-portal-kde` rather than a sandboxed copy. Your steps still work. Here is a variant that skips qdbusviewer so it runs headless: ```sh #!/bin/sh count() { pgrep -cf /usr/libexec/xdg-desktop-portal-kde; } echo "instances before: $(count)" eval "$(dbus-launch --sh-syntax)" echo "private bus pid: $DBUS_SESSION_BUS_PID" busctl --address="$DBUS_SESSION_BUS_ADDRESS" \ call org.freedesktop.impl.portal.desktop.kde \ /org/freedesktop/portal/desktop \ org.freedesktop.DBus.Peer Ping >/dev/null 2>&1 sleep 3 echo "instances after activation: $(count)" owner=$(busctl --address="$DBUS_SESSION_BUS_ADDRESS" \ status org.freedesktop.impl.portal.desktop.kde 2>/dev/null | sed -n 's/^PID=//p') echo "owns the name on that bus: $owner" kill "$DBUS_SESSION_BUS_PID" sleep 5 echo "bus socket still there: $([ -e "${DBUS_SESSION_BUS_ADDRESS#unix:path=}" ] && echo yes || echo no)" echo "that pid still alive: $([ -d "/proc/$owner" ] && echo yes || echo no)" echo "instances after bus death: $(count)" ``` Output here — the first instance is the session's own, the second is the one this creates: ``` instances before: 1 private bus pid: 265843 instances after activation: 2 owns the name on that bus: 265846 bus socket still there: no that pid still alive: yes instances after bus death: 2 ``` The count goes up by one and stays up. The process that held the name on the private bus is still running after the daemon is dead and its socket is gone; it owns no name anywhere by then and nothing can reach it. Left alone it sits in `S` state indefinitely — the oldest of my 43 was three days old. On Wayland the consequence is different from the "too many clients connected" you mention. Nothing hits an X limit; it just quietly costs memory, and since most of those pages end up swapped out, the visible symptom is the whole desktop stuttering as they get faulted back in. That took me a long time to trace back here, because nothing about the symptom points at portals. I have not looked at the lifecycle code, so I can't say where the missing exit belongs — this is a confirmation, not a diagnosis. Versions, all Fedora RPMs: - xdg-desktop-portal-kde 6.7.4-1.fc44 - xdg-desktop-portal 1.22.1-1.fc44 - Qt 6.11.1 - Fedora 44, Plasma 6.7.4, Wayland session One related observation, not the bug above. While cleaning up after these tests I found that `ksecretd` does the same thing: three instances were still running with `DBUS_SESSION_BUS_ADDRESS` pointing at `/tmp/dbus-*` sockets that no longer existed, one of them nineteen minutes after I had killed the daemon that started it. It gets activated alongside the portal on the same private bus, so in practice these accumulate in pairs — my 43 stale portals came with 43 stale `ksecretd` processes. Whether that is the same root cause or a separate one in kwallet's portal I can't say. -- You are receiving this mail because: You are watching all bug changes.
