'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 -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
