Red Hat Bugzilla – Bug 405351
pulseaudio stores incorrect pid number
Last modified: 2008-03-28 18:34:13 EDT
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
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 |
[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
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
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: pid.c: Stale PID file, overwriting."
messages than before.
Thanks for the fix.
(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: 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
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?