Description of problem: I've had my laptop on for a few days, with a few hibernates in there. I noticed pulseaudio seemed to be crashed or not running as I ran pavucontrol and it said it couldn't make a connection (connection refused.) So I tried to pkill -9 pulseaudio, and then restart pulseaudio by running 'pulseaudio' well, that didn't work - [duffy@yuna ~]$ pulseaudio E: pid.c: Daemon already running. E: main.c: pa_pid_file_create() failed. Tried to pkill it again, run it again, same. Did a ps ax | grep pulse: [duffy@yuna ~]$ ps ax | grep pulse 3766 pts/7 S+ 0:00 grep pulse [duffy@yuna ~]$ Tried to run it again, same. Did pulseaudio strace and saw it was looking at /tmp/pulse-duffy/pid, so I went there, and the pid it had was 2590. ran ps ax | grep 2590: [duffy@yuna ~]$ ps -ef | grep 2590 duffy 2590 1 0 Nov28 ? 00:00:12 /usr/libexec/gnome-settings-daemon duffy 3775 3349 0 23:04 pts/7 00:00:00 grep 2590 [duffy@yuna ~]$ So, it may be that the pid numbers on my machine started wrapping since it's been on for a while. But gnome-settings-daemon is something that runs at startup, so it doesn't make sense that it would get a small pid after the machine was on long enough to rewrap? Unless it crashed? What do you think?
gnome-settings-daemon respawns when it dies, so there is a chance it stole the old pid. Unfurtunatelly the program doesn't have much chances to see if one that uses his former PID is an instance of himself. This also applies to initscripts -- have a look at /etc/init.d/functions to see what __pids_var_run() does. Maybe solution to this would be checking if /proc/PID/exe matches /proc/self/exe
*** Bug 425763 has been marked as a duplicate of this bug. ***
Lennart reports on fedora-devel that this fix (checking /proc/PID/exe for match) is in recent version. Is that fix in rawhide?
Tom: It is.
I've removed my 'boot up fix' of "rm -rf /tmp/pulse-*" on 13 March, and pulseaudio has started up perfectly each time I booted. I have many more "pulseaudio[2916]: pid.c: Stale PID file, overwriting." messages than before. Thanks for the fix. Close this?
(In reply to comment #5) > I've removed my 'boot up fix' of "rm -rf /tmp/pulse-*" on 13 March, and > pulseaudio has started up perfectly each time I booted. > > I have many more "pulseaudio[2916]: pid.c: Stale PID file, overwriting." > messages than before. What are they caused by? How do you shut down your computer? Do you loose power often, or experience crashes? > Close this? No. See "Summary" for what is this bug filed for.
It is my understanding that, since the PID file is stored in /tmp, it is not cleaned out during normal shutdown. The next time you boot this file is probably still there, and there is some likelihood the PID in the file will collide with some other process. The original pulseaudio code only checked for the existence of the PID file and an active process with that PID. It did not check if the PID 'pointed' to a copy of pulseaudio. Believe correcting code has been added to do this check, thus causing the "Stale" messages.
This bug has been fixed a while back upstream and in rawhide. Closing.
So you are not going to fix this in an F8 update?