On 6 Jul 2014 14:48, "Michael Meskes" <mes...@debian.org> wrote: > > > If a client tries to repeatedly connect then yes, it could respawn > > pulseaudio pretty fast. But this seems unlikely, given that the log > > does not show multiple messages. What happens if you have the wrong > > line and disable autospawn? > > Then it works.
Ok, so it seems the problem is indeed autospawn related. I think something within your session startup sequence cannot handle pulseaudio dying. Do oy > > > Honestly I haven't checked since finding my problem, but it may also > > > have to do with a non-existing default sink. Anyway, I shall try again and > > > report back. > > > > Please do so, also trying with a disabled autospawn. > > Bad idea, the misconfigured default-sink was not reason for my problems as > just > "enabling" the alsa sink module created the same problem again. My screen > stayed black again. At the very same moment I had, like, seven pulseaudio > processes running at the same time, albeit no log entry at all this time. Hmm, there seems to be some sort of race at pa startup, with multiple pa daemons getting autospawned. But are there any more logs in syslog (after the crash)? Because it seems strange to me that pa won't log anymore if the config is the problem. If you can reproduce this again, can you open a VT or ssh into your system or otherwise poke into the pulseaudio daemons? Please install the dbg packages and then try to get a backtrace of each of the pulseaudio daemons (`gdb -p $pid`). Also please post the output of `ps aux | grep pulseaudio` (before running gdb). > However, I did manager to lose all my desktop configuration this time. I guess > the next time I try I better use a test user. :) :( I'm sorry to hear that. Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
