Maintains too many open connections to pipewire (and pulseaudio) sound server on Linux, exhausting system
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
People
(Reporter: tim.w.connors, Unassigned, NeedInfo)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Steps to reproduce:
Started a firefox instance after a clean reboot, not running the usual hundreds of tabs open that I usually have open (so not just your usual run-of-the-mill overloading), and interacted with it in a rarely lightweight fashion for a day. This has happened before, but not usually after only a day. Often weeks or (small number) month, complete unpredictably (although this time there was a brief network interruption within a minute of the loss of sound).
Actual results:
After a day or so, anything requesting sound (eg, youtube videos) causes the entire browser to hangup for a minute before coming back, but with no sound. Pause and play the video, another hangup. Video reaches end, another hangup.
I noticed in my syslogs a pipewire message that started at the time this became a problem (and has every other time I've encountered such hangups):
Jun 30 20:00:58 dirac pipewire-pulse[3961]: mod.adapter: can't load spa node: Too many open files
Jun 30 20:00:58 dirac pipewire-pulse[3961]: mod.adapter: usage: node.name=<string>
Jun 30 20:00:58 dirac pipewire-pulse[3961]: pw.resource: usage: node.name=<string>
Jun 30 20:00:58 dirac pipewire-pulse[3961]: pw.stream: 0x55b47a531000: can't make node: Invalid argument
Jun 30 20:01:01 dirac pipewire-pulse[3961]: mod.protocol-pulse: server 0x55b478398a90: failed to create client: Too many open files
Many bugs open in the linux pipewire issues, most of them relating to firefox:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4047
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4378
(and a not-firefox one, that is also of relevance because of pavucontrol: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2208 )
pw-cli ls Node
id 30, type PipeWire:Interface:Node/3
object.serial = "30"
factory.id = "11"
priority.driver = "200000"
node.name = "Dummy-Driver"
id 31, type PipeWire:Interface:Node/3
object.serial = "31"
factory.id = "11"
priority.driver = "190000"
node.name = "Freewheel-Driver"
id 51, type PipeWire:Interface:Node/3
object.serial = "52"
factory.id = "11"
client.id = "48"
priority.session = "100"
priority.driver = "1"
node.name = "Midi-Bridge"
media.class = "Midi/Bridge"
id 54, type PipeWire:Interface:Node/3
object.serial = "56"
object.path = "alsa:acp:Generic:11:playback"
factory.id = "19"
client.id = "48"
device.id = "50"
priority.session = "736"
priority.driver = "736"
node.description = "Starship/Matisse HD Audio Controller Digital Stereo (IEC958)"
node.name = "alsa_output.pci-0000_04_00.0.iec958-stereo"
node.nick = "ALCS1200A Digital"
media.class = "Audio/Sink"
id 55, type PipeWire:Interface:Node/3
object.serial = "57"
object.path = "alsa:acp:Generic:0:capture"
factory.id = "19"
client.id = "48"
device.id = "50"
priority.session = "2009"
priority.driver = "2009"
node.description = "Starship/Matisse HD Audio Controller Analog Stereo"
node.name = "alsa_input.pci-0000_04_00.0.analog-stereo"
node.nick = "ALCS1200A Analog"
media.class = "Audio/Source"
id 58, type PipeWire:Interface:Node/3
object.serial = "558"
factory.id = "14"
client.id = "48"
node.description = "BLE MIDI 1"
node.name = "bluez_midi.server"
media.class = "Midi/Bridge"
id 98, type PipeWire:Interface:Node/3
object.serial = "29630"
factory.id = "7"
client.id = "94"
client.api = "pipewire-pulse"
application.name = "XMMS2"
node.name = "XMMS2"
media.class = "Stream/Output/Audio"
pw-top -b -n1
S ID QUANT RATE WAIT BUSY W/Q B/Q ERR FORMAT NAME
C 30 0 0 --- --- --- --- 0 Dummy-Driver
C 31 0 0 --- --- --- --- 0 Freewheel-Driver
C 51 0 0 --- --- --- --- 0 Midi-Bridge
C 54 0 0 --- --- --- --- 0 alsa_output.pci-0000_04_00.0.iec958-stereo
C 55 0 0 --- --- --- --- 0 alsa_input.pci-0000_04_00.0.analog-stereo
C 58 0 0 --- --- --- --- 0 bluez_midi.server
C 98 0 0 --- --- --- --- 0 XMMS2
My pipewire-pulse process has 1024 open file descriptors, mostly (deleted?) memory segments. They mostly seem to correspond to similar (deleted?) file descriptors in firefox.
And pw-dump, lsof on all firefox processes and pipewire-pulse process attached because they're too big/too many for inline.
From experience, when I restart pipewire-pulse, I will resume normal functionality (although lose the ability to grab more diagnostics until this happens next time weeks down the line).
Expected results:
Sound should still be working, no hangups, no exhaustion of open sound server connections (especially when there's not all that much open that can consume resources.
Reporter | ||
Comment 1•4 months ago
|
||
Open file descriptors
Comment 2•4 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Reporter | ||
Updated•4 months ago
|
Comment 3•3 months ago
|
||
The severity field is not set for this bug.
:jimm, could you have a look please?
For more information, please visit BugBot documentation.
Description
•