User Agent: Mozilla/5.0 (X11; Linux i686; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20180128191456 Steps to reproduce: I am using Firefox Quantum 59.0b5 (32-bit) with the following setup: Debian GNU/Linux 8.10 (jessie) 3.2.0-3-686-pae with dwm window manager, pulseaudio 7.1-2~bpo8+1 Pulseaudio is started with "pulseaudio --start" in user's .xinitrc. I had started firefox by executing it's binary file and the browser worked perfectly with audio. I then shutdown firefox and restarted it after a while. Actual results: Firefox started normally but failed to play any audio with 'to play audio you may need to install the required pulseaudio...' message issued. It turned out that Pulseaudio didn't respawn as it normally should. Manual start of pulseaudio with both start-pusleaudio-x11 and pulseaudio --start immediately resores sound in Firefox, but shutting FF down again also kills pusleaudio, and starting FF doesn't cause it to start again. Expected results: Firefox should has been able to respawn (start) PulseAudio when the PulseAudio server was down and to play sound.

I'm noticing the same issue with Firefox 58.0.1: PulseAduio is configured to start only when needed and to exit if not needed anymore but starting Firefox does not cause the pulseaudio process being started resulting in no sound/Firefox claiming about PulseAudio eventually not being installed. This worked in Firefox 57.0.1 and reverting back fixes this issue. Alternatively pulseaudio can be started manually from a terminal as a workaround.

Edit: This regression does appear for me on a x86_64 (amd64) architecture.

Dan, is there anything we should be doing here?

I defer to Matthew on this one. Matthew, do you know about `pulseaudio --start`?

Is this related to https://bugzilla.mozilla.org/show_bug.cgi?id=1422073 , since I get expected results with: MOZ_DISABLE_CONTENT_SANDBOX=1 firefox and it says fixed in 59

There's a period of time (58 until it was enabled in 59) where the sandbox restrictions were increased such that Firefox no longer had permissions to spawn the PulseAudio server... this is ultimately addressed by changes in 59, where the audio is remoted to the chrome process (without restricted privileges). So that's related to bug 1422073. The other part of this bug report needs further investigation - why is PulseAudio, started from the X session, terminating after being used by Firefox? Can anyone who is seeing this issue please run PulseAudio with logging enabled (https://wiki.ubuntu.com/PulseAudio/Log), reproduce the situation where PA terminates after being used by Firefox, and then post the logs?

The content process hasn't been allowed to start the PulseAudio daemon while sandboxed since sandboxing was enabled — even if we allowed the fork and execve syscalls, the daemon would inherit the content process's seccomp-bpf policy and would break. (Specifically, the first time ld.so tries to open or stat a file, it would raise SIGSYS and immediately die because Firefox's SIGSYS handler is no longer present.) As a result, in bug 1259508 we initialized audio before starting the sandbox, to allow for starting the PulseAudio daemon (or anything else along those lines. But that was removed in bug 1405877, and it wasn't conditional on the "media.cubeb.sandbox" pref, which is where bug 1434156 comes in. So that would explain why it's broken in 59 (and will be fixed in 60) if the daemon isn't already running. It might also explain problems if the daemon is set to auto-exit on idle and a sandboxed content process tries to restart it, but *that* should have started breaking in 54, not 58. (Or maybe 57, if there were non-e10s-compatible extensions that were forcing single-process mode before they were desupported… but not 58.)

(In reply to Jed Davis [:jld] (⏰UTC-7) from comment #7) > It might also explain problems if the daemon > is set to auto-exit on idle and a sandboxed content process tries to restart > it, but *that* should have started breaking in 54, not 58. If I'm not wrong the pulseaudio process never exited here while Firefox was running even if all tabs were being closed (on a test I see 2 firefox processes in that case - 1 without arguments and 1 -contentproc) - it was always required that Firefox was completely closed before the pulseaudio process was also able to exit.

(In reply to me from comment #0) > Debian GNU/Linux 8.10 (jessie) 3.2.0-3-686-pae To make things more complicated: This kernel is too old for sandboxing; the “Sandbox” section of about:support should confirm that. There could be something else going on here, maybe a side-effect of inheriting LD_LIBRARY_PATH and/or LD_PRELOAD from the content process. (Note: Ubuntu's 3.2.0 kernels have seccomp-bpf because Chromium sandbox devs worked with them to backport it for their 12.04 release, but for Debian it's in 3.5, same as the mainline kernel.) Also, I just tried to reproduce what I described in comment #7 on Debian unstable, and failed: the PulseAudio daemon was spawned by systemd instead of directly by the client.

With the help of a Debian 8 VM, I've figured out the other half of this bug, and the reason it's happening on 58: bug 1412464. The PulseAudio daemon inherits the content process's environment, including LD_PRELOAD, so when we use the libmozsandbox.so preload to replace inotify_init (which we don't need) with a stub that always returns an error, that also applies to PulseAudio (which does need it). Specifically, this causes an error in module-udev-detect initialization. So we *do* try to pre-start pulseaudio, but it doesn't work, and then we try again after the sandbox is started and get a similar failure to bug 1443612, but for different reasons. And it turns out the right place to look for additional information here is /var/log/user.log: Mar 7 12:44:17 debian8 pulseaudio[22081]: [pulseaudio] module-udev-detect.c: inotify_init1() failed: Function not implemented Mar 7 12:44:17 debian8 pulseaudio[22081]: [pulseaudio] module.c: Failed to load module "module-udev-detect" (argument: ""): initialization failed. Mar 7 12:44:17 debian8 pulseaudio[22081]: [pulseaudio] main.c: Module load failed. Mar 7 12:44:17 debian8 pulseaudio[22081]: [pulseaudio] main.c: Failed to initialize daemon. Mar 7 12:44:17 debian8 pulseaudio[22078]: [pulseaudio] main.c: Daemon startup failed.

Comment on attachment 8957049 [details] Bug 1434392 - Don't preload libmozsandbox in grandchild processes, only the sandboxed children themselves. https://reviewboard.mozilla.org/r/226010/#review232006

Pushed by jedavis@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/07b6161c7f60 Don't preload libmozsandbox in grandchild processes, only the sandboxed children themselves. r=gcp

Only for future reference: for people who run into the issue of pulseaudio exiting and Firefox failing to restart it again, especially in fully automated test environments, it might help to set "--exit-idle-time=-1" in you pulseaudio config http://manpages.ubuntu.com/manpages/trusty/man5/pulse-daemon.conf.5.html

Should we keep this on the radar as a possible dot release ride along, or is this enough of a corner case that it can ride with 60?

Is this actually a corner case? On Ubuntu the default value for exit-idle-time is 20 which would make me think that even on a default Ubuntu installation pulseaudio would always exit after 20 seconds being unused - but I have never tested it on an out of the box installation.

(In reply to sworddragon2 from comment #18) > Is this actually a corner case? On Ubuntu the default value for > exit-idle-time is 20 which would make me think that even on a default Ubuntu > installation pulseaudio would always exit after 20 seconds being unused - > but I have never tested it on an out of the box installation. The default Ubuntu desktop environment appears to have 4-5 connections to PulseAudio at all times, which would make exit-idle-time irrelevant if I understand correctly.

(In reply to Julien Cristau [:jcristau] from comment #17) > Should we keep this on the radar as a possible dot release ride along, or is > this enough of a corner case that it can ride with 60? Yes, I think we should consider it for 59.0.x, but see bug 1443612 comment #10: this patch won't uplift cleanly, and for 59 we can back out bug 1412464 and bug 1408497 instead, so I propose doing that as the lower-risk approach. Should I attach a patch for those backouts to this bug and flag it for release approval?

Bug 1443612 is now wontfix for 59, so there's no benefit to uplifting this half.