Bug 405351 - pulseaudio stores incorrect pid number
Summary: pulseaudio stores incorrect pid number
Alias: None
Product: Fedora
Classification: Fedora
Component: pulseaudio
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
: 425763 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-11-30 04:10 UTC by Máirín Duffy
Modified: 2008-03-28 22:34 UTC (History)
9 users (show)

Clone Of:
Last Closed: 2008-03-28 20:19:49 UTC

Attachments (Terms of Use)

Description Máirín Duffy 2007-11-30 04:10:59 UTC
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?

Comment 1 Lubomir Kundrak 2007-12-20 11:28:55 UTC
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

Comment 2 Lennart Poettering 2008-02-15 16:50:33 UTC
*** Bug 425763 has been marked as a duplicate of this bug. ***

Comment 3 Tom London 2008-03-14 14:03:47 UTC
Lennart reports on fedora-devel that this fix (checking /proc/PID/exe for match)
is in recent version.

Is that fix in rawhide?

Comment 4 Lubomir Kundrak 2008-03-21 12:12:25 UTC
Tom: It is.

Comment 5 Tom London 2008-03-21 13:49:33 UTC
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?

Comment 6 Lubomir Kundrak 2008-03-21 14:23:40 UTC
(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.

Comment 7 Tom London 2008-03-21 14:32:22 UTC
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.

Comment 8 Lennart Poettering 2008-03-28 20:19:49 UTC
This bug has been fixed a while back upstream and in rawhide. Closing.

Comment 9 Joe Orton 2008-03-28 22:34:13 UTC
So you are not going to fix this in an F8 update?

Note You need to log in before you can comment on or make changes to this bug.