Pipewire server deadlocks on blocking system call randomly
- PipeWire version (
pipewire --version
): 1.0.3 (and earlier) - Distribution and distribution version (
PRETTY_NAME
from/etc/os-release
): Arch Linux - Desktop Environment: Xfce
- Kernel version (
uname -r
): 6.6.16-1-lts
Description of Problem:
The pipewire deamon randomly enters an uninterruptible "disk sleep (D)" state. When this happens all audio playback becomes impossible and even rebooting the system is impossible because systemd will wait forever on pipewire to shutdown. Starting any audio playback or interaction through pw-cli etc. will freeze the application. The deamon will not respond to any signals (SIGTERM, SIGKILL etc.)
The only way to recover from this state is to forcibly shutdown the system with a hardware reset or SysRq + b
.
How Reproducible:
Non-deterministically once a week, more prevalent when using audio editing software like audacity.
Steps to Reproduce:
Happens randomly; the following steps make it much more likely to happen but are not mandatory.
- Open any sound file in audacity.
- Select some section of audio to play in a loop (preferably short - i suspect this has something to do with the sound buffer handling)
- Let it loop until all system audio cuts out.
- Now starting any audio playback or even connecting to the sound server will freeze it's client application.
- Verify that pipewire daemon is blocked (e.g.:
cat /proc/$(pgrep -x pipewire)/status
)
Other ways to reproduce:
- Play media with mpv, skipping around.
- Edit sound with ardour
For some reason streaming media with Firefox is much less likely to cause it. The file has to be on disk.
Actual Results:
Pipewire deamon deadlocks in uninterruptible disk sleep. Service restart and even reboot is impossible.
Effectively this causes a denial of service for the whole system.
Expected Results:
Audio keeps playing, or at least pipewire crashes (and restarts), anything that does not prevent a normal shutdown.
Comparison to pulseaudio: sometimes my USB soundcard seems to crap itself and crash. When this happens sometimes the pulseaudio server chrashes and no audio output is possible. However in this case restarting pulsaudio fixes the problem. In most cases unplugging/replugging the soundcard is enough. This simple fix does not work at all when using pipewire.
Additional Info (as attachments):
-
pw-dump > pw-dump.log
: Not possible because it freezes! -
journalctl
: -
`cat /proc/$(pgrep -x pipewire)/stack`
[<0>] usb_kill_urb.part.0+0x92/0xd0 [<0>] usb_hcd_flush_endpoint+0xb8/0x180 [<0>] usb_disable_endpoint+0x57/0xb0 [<0>] usb_set_interface+0x90/0x3c0 [<0>] endpoint_set_interface+0x39/0xe0 [snd_usb_audio] [<0>] snd_usb_endpoint_close+0xfc/0x110 [snd_usb_audio] [<0>] snd_usb_hw_free+0x8c/0xe0 [snd_usb_audio] [<0>] snd_pcm_common_ioctl+0xe2b/0x12e0 [snd_pcm] [<0>] snd_pcm_ioctl+0x2e/0x50 [snd_pcm] [<0>] __x64_sys_ioctl+0x97/0xd0 [<0>] do_syscall_64+0x60/0x90 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
-
While researching this issue i found a special set of uninterruptible blocking syscalls which can be interrupted if the calling process is killed anyways. Maybe these can be used to at least make pipewire crash cleanly instead of causing a denial of service for the whole system?
-
This issue is exclusive to pipewire and did not happen with pulseaudio. (switching back to pulse is a functioning workaround)