On Tue, 20.05.08 05:47, Kevin Kofler (kevin.kofler@xxxxxxxxx) wrote: > > Lennart Poettering <mzerqung <at> 0pointer.de> writes: > > Also, if you claim that I neglect longstanding important bugs, then > > please be more specific and tell me exactly the bug numbers. > > There's this one: > https://bugzilla.redhat.com/show_bug.cgi?id=438284 > "Sometimes, PulseAudio fails to start" > It might actually be a symptom of several completely different bugs. What I'm > seeing in KDE is that sometimes, for no apparent reason, no PA is running, > starting it with pulseaudio -D just starts it. But that only happens sometimes. > I know this is not very useful as a bug report, I'll have to check the logs > more carefully to see if I can figure out what happens: maybe PA starts up and > then kills itself due to CPU overload? I'll let you know once I figure out > more. I was pretty sure I fixed that issue, as I wrote in the bug report. /me reads the sources. Ah, ok, it's like this: I actually did fix this issue, but not completely. PA does check the exename of an existing PID file to check if it is actually pa that owns the PID if it is still running. However, I added this fix only when killing an existing daemon (i.e. -k), not when starting a new one. It's trivial to fix. Hmm, this bug seems to be triggered only by KDE. Apparently in KDE PA is not configured for module-x11-xsmp? (could anyone who actually runs KDE check this?) if that module is not loaded libX11 will forcibly terminate us as soon as the X11 connection goes away. This will cause the PID file to not be removed properly on shutdown. > Then there's this weird issue: > https://bugzilla.redhat.com/show_bug.cgi?id=361891 What's weird about this issue is primarily the setup (i.e. running arts on top of pa). If you stack sound servers like this it is a call for trouble. Just don't do it. Sound servers should live near the hardware, not on top of each other. I mean, it would be great if this worked fine, but please understand that bug reports where the first thing I think when reading it is "Oh my, why do they want to do weird things like that?" are not the kind of bug reports that become a top priority for me to fix. And the fact that it's a bug in conjunction with obsolete, bit-rotten C++ software doesn't help it either. If you trigger one of those CPU overload issues, than this is most likely due to the software entering some kind of busy loop. If you want to fix this, you need to find out why we enter this busy loop. Apparently the operation that should normally sleep for IO doesn't sleep for IO in this case. Usually this means that an IO condition that was signalled earlier was not handled as it should and thus not reset. Unfortunately bugs like this don't leave any useful coredumps, error messages or back traces and so can only be fixed by spending some time in gdb to figure out what happens. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
