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 -- 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
