[pulseaudio-discuss] Issue with access

[Fred Frigerio]

On Tue, Jul 19, 2011 at 1:29 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Fred Frigerio at 19/07/11 12:38 did gyre and gimble:
>> On Tue, Jul 19, 2011 at 4:27 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>>> 'Twas brillig, and Fred Frigerio at 19/07/11 02:03 did gyre and gimble:
>>>> On Mon, Jul 18, 2011 at 8:38 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>>>>> 'Twas brillig, and Fred Frigerio at 18/07/11 12:38 did gyre and gimble:
>>>>>> On Mon, Jul 18, 2011 at 4:53 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>>>>>>> 'Twas brillig, and Fred Frigerio at 17/07/11 22:46 did gyre and gimble:
>>>>>>>> I have a strange problem. I have been running pa for a long time under
>>>>>>>> gentoo x86. However from a couple of days back it is not working
>>>>>>>> anymore (it was after a round of updates but I can't pinpoint what
>>>>>>>> might have done it)
>>>>>>>>
>>>>>>>> I can start pulseaudio -v without a problem. However I cannot connect
>>>>>>>> to it afterwards and I get the following error in syslog.
>>>>>>>>
>>>>>>>> pulseaudio[18226]: pid.c: Daemon already running.
>>>>>>>>
>>>>>>>>
>>>>>>>> Any help would be appreciated.
>>>>>>>>
>>>>>>>> This is what I get when starting pulseaudio -v
>>>>>>>
>>>>>>>> I: alsa-util.c: Error opening PCM device hw:0: Device or resource busy
>>>>>>>
>>>>>>> This implies some other application already has PA open.
>>>>>>>
>>>>>>> Some debug is needed I think.
>>>>>>>
>>>>>>> Can you attach (as .txt files) the output from:
>>>>>>>
>>>>>>> ck-list-sessions
>>>>>>> getfacl /dev/snd/*
>>>>>>> sudo fuser -v /dev/snd/pcm*
>>>>>>> ps aux | grep pulse
>>>>>>> xprop -root | grep PULSE
>>>>>>>
>>>>>>
>>>>>> Here it goes. The output from the fuser command is empty (I did run it
>>>>>> as root). Also I am running gnome (2.32).
>>>>>
>>>>> That's cool. fuser output being empty is semi-expected (when it's not
>>>>> empty, it can cause problems.
>>>>>
>>>>>
>>>>> OK, so all this looks to be good so far. PA is running, but what is
>>>>> interesting is that the PULSE_SERVER string is not present in your xprop
>>>>> output....
>>>>>
>>>>> Can you try this:
>>>>>
>>>>> PULSE_LOG=99 pactl stat
>>>>>
>>>>
>>>> See attached. The interesting bit is that it is looking for a native
>>>> file|pipe? that just isn't there. There is a pid file in that
>>>> directory but that's it.
>>>
>>> I think you forgot the attachment?
>>>
>>>
>>> But the fact that it's trying to access the native socket and that
>>> doesn't exist is telling....
>>>
>>> It also explains why PA is running but you were allowed to start another PA.
>>>
>>> So I'd suggest that *something* is going on with your filesystem that is
>>> "interesting". I suspect that PA is starting, writing it's various
>>> sockets and metadata files, and then having them removed from it by some
>>> other process...
>>>
>>> Can you do "ls -l ~/.pulse"?
>>>
>>>
>>> Can you think of anything that would cause this. I suspect that it's
>>> probably related to $TMPDIR getting cleaned out over vigorously.
>>>
>>
>> I can't think of what might be going on. The only item with /tmp that
>> I can think of is that I switched it from an old hard drive to a new
>> one in a mirror configuration. Could it be some 'bad' choice during
>> the kernel config?
>
> Thanks for that.
>
> Can you possibly do a couple things. I should really have asked for
> these before :s
>
>
> cat /var/lib/dbus/machine-id
> ls -ld /tmp/pulse-*
>
> Essentially, we create a symlink to a /tmp folder for our "runtime"
> directory. This is more complicated than you might think as we have to
> deal with e.g. NFS /home's which means we cannot use /home for our
> socket files (sockets don't get on very well with NFS). Thus we specify
> that /tmp (or rather $TMPDIR) is a good place to keep our socket.
>
> Now we cannot use a fixed folder name in here as some other evil user
> may create this fixed filename and effectively cause us a DoS (this
> happened with ESD for example).
>
> This is why we use random path names in /tmp like
> /tmp/pulse-42GylJI0UpHW and symlink this to our known path in ~/.pulse.
>
> I suspect the ultimate problem just relates to the fact that /tmp is
> either a filesystem that doesn't support permissions or socket files
> (e.g. fat32), or something else happens to delete the /tmp/pulse* files
> inside /tmp after PA has started.
>
> If you want to try and restart PA after logging in, you'll have to do:
>
> killall pulseaudio
> start-pulseaudio-x11
>
> Normally "pulseaudio -k" would be enough to kill PA, but as we cannot
> access the runtime dir, this "nice" method won't work.
>
>
> Hopefully this points you in the right direction, but if not we can try
> and debug further ;)
>
> Col
>

I think you got it. It is probably a mount option for tmp. I'll look
that up when I get home.

I REALLY appreciate your help.

Thank you,

Fred