Arch Linux

mesaprotector

Member

Registered: 2024-03-03

Posts: 167

Wireplumber hanging shutdown and causing other mayhem

Could not find much about this online. It used to be inconsistent, but now most of the time when logging off or shutting down, the wireplumber user service hangs and doesn't exit for 90 seconds.

On logout, it hangs for only a few seconds but then hangs for 90 if I try logging back IN, with an unusual message in the system journal: "No PIDs left to attach to the scope's control group, refusing". Switching to a different TTY allows me to log in. I haven't tried seeing if the sound still works on the new TTY.

The following part of the system journal (from a shutdown) seems relevant:

Sep 09 11:23:21 Marojejy systemd[1954]: Stopping Multimedia Service Session Manager...
Sep 09 11:23:21 Marojejy mkinitcpio[2510]:   -> Running build hook: [sd-shutdown]
Sep 09 11:23:21 Marojejy dbus-broker-launch[827]: Activation request for 'org.bluez' failed.
Sep 09 11:23:21 Marojejy avahi-daemon[833]: avahi-daemon 0.8 exiting.
Sep 09 11:23:21 Marojejy wireplumber[2099]: wireplumber: stopped by signal: Terminated
Sep 09 11:23:21 Marojejy systemd[1]: avahi-daemon.service: Deactivated successfully.
Sep 09 11:23:21 Marojejy systemd[1954]: Stopped D-Bus User Message Bus.
Sep 09 11:23:21 Marojejy systemd[1]: Stopped Avahi mDNS/DNS-SD Stack.
Sep 09 11:23:21 Marojejy wireplumber[2099]: m-dbus-connection: <WpDBusConnection:0x5b89237aad60> DBus connection closed: Underlying GIOStream returned 0 bytes on an async read
Sep 09 11:23:21 Marojejy wireplumber[2099]: m-dbus-connection: <WpDBusConnection:0x5b89237aad60> Trying to reconnect after core sync
Sep 09 11:23:21 Marojejy wireplumber[2099]: wireplumber: disconnected from pipewire

Sep 09 11:24:51 Marojejy systemd[1954]: Stopped Multimedia Service Session Manager.

I have temporarily set the timeout for wireplumber to stop to 1 second so I don't have to deal with all this, but I'll set it back if there's anything I can do to debug further.

Possibly unrelated, but logging out from kitty stopped working at right about the same time. If I try "logout" in kitty now it closes the terminal and does nothing else.

EDIT: Setting the timeout to 1 second didn't help. So I just set TimeoutStopFailureMode to kill and will pray it doesn't happen again.

Last edited by mesaprotector (2024-09-10 00:05:12)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 23,430

Re: Wireplumber hanging shutdown and causing other mayhem

Sounds like your user session is broken in some form in general.

printenv
loginctl session-status

mesaprotector

Member

Registered: 2024-03-03

Posts: 167

Re: Wireplumber hanging shutdown and causing other mayhem

Well, it definitely is broken somehow. Note that I switched from pipewire to pulseaudio to see if that fixed anything in all of the below.

Here is a concatenation of "printenv", "loginctl session-status 1", "loginctl session-status 2", "loginctl user-status", while still logged in as my user (asuka): https://0x0.st/Xxm_.txt
And here is a concatenation of "loginctl session-status 2" and "loginctl user-status asuka", while logged in as root from another tty while the session is still failing to close: https://0x0.st/Xxmf.txt
For comparison, "printenv" as root: https://0x0.st/Xxm3.txt

top shows 3 (sometimes 5, with duplicates) zombie processes when the hang occurs - dbus-broker, dbus-broker-lau, and pulseaudio.

Checking systemctl list-jobs found that user-runtime-dir@1000.service is waiting while the hang occurs. Looking within the /run/user/1000 directory the only subfolders are bus, dconf, gnupg, p11-kit, pulse, and systemd. While X11 is running there are others, but the hang occurs regardless of that so I've just been testing it on the tty.

EDIT: For whatever reason "logout" does not hang, but "loginctl user-terminate asuka" does.

EDIT2: Seems to be the result of me changing KillMode of user@.service to control-group from mixed. Unfortunately if it's set to mixed everything gets instantly killed with no chance to exit cleanly, which is unacceptable. I don't know why it takes 90 seconds to stop; user@.service's own timeout is 120.

Last edited by mesaprotector (2024-09-10 22:02:14)