<div dir="ltr">Tanu,<div>Thanks for your response and good troubleshooting ideas.</div><div>You wrote:<br></div><div>>First of all, home-directory-on-NFS *should* be supported just fine.<br></div><div>>The whole purpose of using the /tmp/pulse directories is to make this<br>>use case work.<br></div><div>Here's what I found.</div><div>The first place I looked was in the ~/.pulse directory and found an interesting</div><div>problem. No matter how many of our workstations I logged in to, there was still</div><div>only one set of asdfasdfasdf:xxx files, hence only one asdfasdfasdf:runtime link.</div><div>So, when I logged onto a workstation, it was the only one that had a valid link to</div><div>a /tmp/pulse-yyyy directory! This is the case for every user. I now suspect this is</div><div>an operating environment issue and not directly related to Pulse. Another data point is that I went to another network I work on with the same Linux environment; however, it just has a simple NFS mount for my home directory. On that network, I had many host ID entries in my</div><div>~/.pulse area.</div><div>I need to find out more about how our user accounts/directories are managed, I believe</div><div>there is something having to do with LDAP involved. I am wondering which machine belongs</div><div>to the ID I find in everyones ~/.pulse directory.</div><div>Do you know how that ID is generated.</div><div>One other thing. I was successfully able to operate in system-wide daemon mode, so</div><div>that is a viable option. However, I had a problem automatically launching it from</div><div>/etc/rc.d/rc.local at boot time. I used the same command that I used as root from the command line.</div><div>In /var/log/messages it reported that it could not create a /var/run/pulse directory, which</div><div>already exists and is owned by pulse. Not sure why it works from the command line</div><div>as root by not at boot.</div><div>Thanks again for your help.</div><div>Bob</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 9, 2016 at 8:00 AM, <span dir="ltr"><<a href="mailto:pulseaudio-discuss-request@lists.freedesktop.org" target="_blank">pulseaudio-discuss-request@lists.freedesktop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">------------------------------<br> <br> Message: 5<br> Date: Fri, 09 Sep 2016 14:52:02 +0300<br> From: Tanu Kaskinen <<a href="mailto:tanuk@iki.fi">tanuk@iki.fi</a>><br> To: <a href="mailto:pulseaudio-discuss@lists.freedesktop.org">pulseaudio-discuss@lists.<wbr>freedesktop.org</a><br> Subject: Re: [pulseaudio-discuss] Multi Workstation Single Home<br> Directory NFS Mount<br> Message-ID: <<a href="mailto:1473421922.32735.45.camel@iki.fi">1473421922.32735.45.camel@<wbr>iki.fi</a>><br> Content-Type: text/plain; charset="UTF-8"<br> <br> On Thu, 2016-09-08 at 17:51 -0400, rjs wrote:<br> > Hi,<br> > First off, I am running on RedHat 6, not under my control, so I have pulse<br> > 0.9.22.<br> > I am running in normal user mode and everything is generally fine.<br> > The issue is that we have multiple workstations and my user account is<br> > NFS mounted across all workstations in the same directory.<br> > If I have pulse running on one, then I get on another workstation and get<br> > pulse running, the first, and eventually the second go out to lunch.<br> > No applications can connect, pacmd returns:<br> > "No PulseAudio daemon running, etc."<br> <br> Note that pacmd is not like other applications. Normal applications<br> should autospawn pulseaudio if it's not running, pacmd won't do that.<br> <br> > In addition, I believe the pulseaudio process stops and restarts every 5<br> > seconds, generating many /tmp/pulse-.... directories.<br> <div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>First of all, home-directory-on-NFS *should* be supported just fine.<br></div><div>The whole purpose of using the /tmp/pulse directories is to make this<br>use case work.<br></div><div><br></div><br> Restarting every 5 seconds is a problem in itself, but even then, that<br> should not generate multiple /tmp/pulse directories. In the ~/.pulse<br> directory there should be one asdfasdfasdf:runtime symlink per machine.<br> The "asdfasdfasdf" part is the machine-id, so every machine has its own<br> symlink to its own /tmp/pulse directory. A new /tmp/pulse directory<br> needs to be created only if the asdfasdfasdf:runtime symlink doesn't<br> exist or points to non-existing target (I think wrong permissions can<br> trigger /tmp/pulse regeneration too).<br> <br> What are the permissions of the asdfadsfasdf:runtime symlink, and what<br> are the permissions of the /tmp/pulse directories? Anything strange in<br> those?<br> <br> What does "PULSE_LOG=99 pactl info" print when things don't work?<br> <br> > By the way, the PID of the pulse instance, on each machine, is contained in<br> > one of those directories, as I expect.<br> > The only way to be able to connect again is to logout on one of the<br> > workstations,<br> > kill pulseaudio, delete all of the /tmp/pulse-... directories, then restart.<br> > Due to our environment, there is no way to avoid this configuration and most<br> > likely cannot update our pulse version.<br> > Is running pulseaudio in system-wide mode an option to solve this?<br> <br> Yes, running in the system-wide mode will likely work around the issue.<br> <br> --<br> Tanu<br> <br> <br> ------------------------------<br> <br> Subject: Digest Footer<br> <br> ______________________________<wbr>_________________<br> pulseaudio-discuss mailing list<br> <a href="mailto:pulseaudio-discuss@lists.freedesktop.org">pulseaudio-discuss@lists.<wbr>freedesktop.org</a><br> <a href="https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/pulseaudio-<wbr>discuss</a><br> <br> <br> ------------------------------<br> <br> End of pulseaudio-discuss Digest, Vol 65, Issue 10<br> ******************************<wbr>********************<br> </blockquote></div><br></div></div></div>