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-* See attached > > 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. > I thought we were onto something there but I don't see anything fancy on the mounting of /tmp. It is ext2 and all I am doing is noatime. Can you think of a kernel choice I might have made that can cause something like this? I am not sure but this problem might coincide with an upgrade to 2.6.38 (gentoo patches r6). -------------- next part -------------- b3211f26c53652cb6a33912f0000004d drwx------ 2 ffrigerio ffrigerio 4096 Jul 19 23:37 /tmp/pulse-xo37JdPuCGUo
