On Thu, 2016-09-08 at 17:51 -0400, rjs wrote: > Hi, > First off, I am running on RedHat 6, not under my control, so I have pulse > 0.9.22. > I am running in normal user mode and everything is generally fine. > The issue is that we have multiple workstations and my user account is > NFS mounted across all workstations in the same directory. > If I have pulse running on one, then I get on another workstation and get > pulse running, the first, and eventually the second go out to lunch. > No applications can connect, pacmd returns: > "No PulseAudio daemon running, etc." Note that pacmd is not like other applications. Normal applications should autospawn pulseaudio if it's not running, pacmd won't do that. > In addition, I believe the pulseaudio process stops and restarts every 5 > seconds, generating many /tmp/pulse-.... directories. First of all, home-directory-on-NFS *should* be supported just fine. The whole purpose of using the /tmp/pulse directories is to make this use case work. Restarting every 5 seconds is a problem in itself, but even then, that should not generate multiple /tmp/pulse directories. In the ~/.pulse directory there should be one asdfasdfasdf:runtime symlink per machine. The "asdfasdfasdf" part is the machine-id, so every machine has its own symlink to its own /tmp/pulse directory. A new /tmp/pulse directory needs to be created only if the asdfasdfasdf:runtime symlink doesn't exist or points to non-existing target (I think wrong permissions can trigger /tmp/pulse regeneration too). What are the permissions of the asdfadsfasdf:runtime symlink, and what are the permissions of the /tmp/pulse directories? Anything strange in those? What does "PULSE_LOG=99 pactl info" print when things don't work? > By the way, the PID of the pulse instance, on each machine, is contained in > one of those directories, as I expect. > The only way to be able to connect again is to logout on one of the > workstations, > kill pulseaudio, delete all of the /tmp/pulse-... directories, then restart. > Due to our environment, there is no way to avoid this configuration and most > likely cannot update our pulse version. > Is running pulseaudio in system-wide mode an option to solve this? Yes, running in the system-wide mode will likely work around the issue. -- Tanu
