On Thu, Mar 13, 2008 at 3:51 PM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Thu, 13.03.08 12:19, Callum Lerwick (seg@xxxxxxxxxx) wrote: > > > > It seems that sometimes on reboot, pulse gets confused and thinks > > > there already is a copy of the daemon running, and so doesn't start > > > one. > > > > > > If you have the "sometimes pulse works and sometimes it doesn't on > > > reboot" situation, you may want to jump on the above BZ. [There is a > > > hack described there that seems to paper over the issue for me.] > > > > I've run in to this myself. Pulse dies or hangs for some reason, leaving > > the lockfile. Then it refuses to start again. Drove me nuts, it took an > > strace run to figure out the lockfile was in /tmp, and not ~/. This is > > not documented in any obvious place. And there's no command line option > > to force start or force cleanup. Epic fail. > > > > Don't we have *libraries* that get this lockfile stuff right? Seems like > > something rather fundamental to unix programming. And yet people still > > manage to do it wrong. > > The problem here is that /var/run is usually cleaned up during bootup, > so it's usually fine to just do a kill(pid, 0) to detect whether a > daemon is already running. However, PA runs as user daemon and thus > cannot write to /var/run. I thus chose /tmp/ copying X and esd a > bit. Which is admittedly a bad idea, and also introduces a (minor) > security issue. > > Recent version of PA check the proc name of the PID they read from the > file before thinking that it is already running. The bug is fixed. > > > Lennart > Cool. Don't see this in the changelog for pulseaudio package. Which version has it, and I'll test. tom -- Tom London -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
