plasma-workspace fallback session launcher duplicates wireplumber alongside PipeWire's context.exec

[KenSpagnolo]

Is this a new report?

Yes

System Info

Void 6.18.51_1 x86_64 AuthenticAMD uptodate rrrrrrmmnFFFF
KDE Plasma 6.7.5, Wayland session, SDDM

Package(s) Affected

plasma-workspace-6.7.5_1 (issue confirmed present at this version; not retested against recent update _2),
pipewire-1.6.8_1,
wireplumber-0.5.17_1

Does a report exist for this bug with the project's home (upstream) and/or another distro?

Not that I could find.

Expected behaviour

Fastfetch and other calls to pipewire run normally, including output for "Sound".

Actual behaviour

Discovered when fastfetch hung calling pipewire to check "Sound".

• pactl info and wpctl status hang indefinitely instead of returning.
• Issue appeared after a reboot; had not occurred before that reboot, despite plasma-workspace having been updated to 6.7.5 a few days earlier.

Steps to reproduce

Behaviour became consistent after reboot. Why it only surfaced now is unconfirmed. The 10-wireplumber.conf symlink predates the plasma-workspace 6.7.5_1 update, so the collision was plausibly already possible before that update. Whether 6.7.5 changed the fallback-launch behavior, or this was simply the first full session since the config was set up, was not established.

How it was confirmed

Confirmed via a logging wrapper in place of the real binary:
mv /usr/bin/wireplumber /usr/bin/wireplumber.real
Contents of new /usr/bin/wireplumber
#!/bin/sh
{
echo "=== wireplumber invoked at $(date '+%Y-%m-%d %H:%M:%S.%N') ==="
echo "My PID: $$"
echo "Parent PID: $PPID"
ps -p "$PPID" -o pid,ppid,comm,args 2>/dev/null
echo "--- parent's parent ---"
GPPID=$(ps -o ppid= -p "$PPID" 2>/dev/null | tr -d ' ')
ps -p "$GPPID" -o pid,ppid,comm,args 2>/dev/null
echo
} >> /tmp/wireplumber-trace.log 2>&1
exec /usr/bin/wireplumber.real "$@"

After a reboot, the trace log showed two invocations:

• One with parent plasma_session --no-lockscreen (direct launch by Plasma).
• One whose immediate parent had already exited by the time ps ran on it — consistent with PipeWire's context.exec fork-and-detach launch.

Workaround
Removing PipeWire's auto-launch config leaves Plasma's direct launch as the sole one:
rm /etc/pipewire/pipewire.conf.d/10-wireplumber.conf

Note: a user-level override (~/.config/pipewire/pipewire.conf.d/10-wireplumber.conf containing context.exec = [ ]) was tried first and did not work — the duplicate launch still occurred, suggesting PipeWire's conf.d merging doesn't let a later empty array override an earlier populated one. Removing the /etc symlink itself is what worked.

Verification
After the workaround and a reboot: exactly one wireplumber process, pactl info returns instantly, fastfetch --stat reports the correct sound device in ~5ms, and the panel no longer freezes.

Question: Should PipeWire's documented context.exec setup and Plasma's own session-launch fallback be reconciled somehow (e.g. Plasma detecting an existing context.exec wireplumber config and skipping its own launch, or the docs/packaging noting the conflict)?

Thank you.

[ahesford]

Please sanitize your Claude output and incorporate the salient details directly in your issue report. Nobody wants to wade through attachments to discover the issue.

[KenSpagnolo]

Done, thanks.

[ahesford]

This is not a bug. The reason that we merely recommend that wireplumber be managed by pipewire itself, rather than enfore that in the package, is that there are multiple possible ways to manage the lifetime of these programs. If you use plasma and the setup manages your sound daemon, just ignore our default recommendation and let plasma do its thing.