Mike Shultz asked:
We have a bunch of Ubuntu desktops with their home directories mounted as NFS shares. If an NFS connection is dropped, even for seemingly less than a second, pulseaudio loses its mind. The results either are a temporary soft-lock(with Ubuntu greying the screen out), crashes, and even a few panics here and there. You can see the myriad of NFS+pulseaudio problems with a simple Google search for those terms.
Due to this, I really want to just move pulse out of /home and put it somewhere more suitable or machine-specific.
For some reason, pulseaudio is all about security. I’m not really downing on this, even though I’m not sure why it’s so important for a sound daemon. But their restrictions set are too constricting.
For instance, I tried symlinking ~/.pulse to /tmp and it will just return the following:
Failed to create secure directory: Too many levels of symbolic links
And pulse will quit.
Then, I ran into this thread which states envitronmental variables that can be set to direct pulse to other directories. So I tried setting up the pulse launcher(
/etc/xdg/autostart/pulseaudio.desktop) to use the following Exec line:
Exec='PULSE_DIR="/tmp/$( whoami )-pulse"; PULSE_CONFIG_PATH=PULSE_DIR; PULSE_STATE_PATH=PULSE_DIR; PULSE_RUNTIME_PATH=PULSE_DIR; mkdir -p $PULSE_DIR && chmod 700 $PULSE_DIR && start-pulseaudio-x11'
I even tried setting the permissions and owner to something I thought pulse would be happy with. I gleaned what I thought it wanted from the stacktrace posted in bug 662(more info about this problem there, as well).
However, this set of commands results in pulse throwing the following and then exiting.
Failed to create secure directory: Permission denied
Now since the developers seem generally unwilling to accept any of this as a problem, I need to find some way to work around this. If not, I’m going to remove pulse, which isn’t ideal for the sake of future compatibility on these machines.
We’ve already wasted a ton of man hours on tracking down and trying to solve this issue and it’s time to move on.
If anyone has any ideas on workarounds or has any more information on this problem, I would really appreciate it.
The PulseAudio developers don’t seem to like a lot of things, one of which is this workaround:
Use PulseAudio as a system daemon, rather than running it per-user.
As I mentioned, the developers don’t particularly recommend this, for their own reasons. If you do this, be aware of the potential security impact on your systems.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.