[pulseaudio-discuss] PulseAudio shared memory files
brian.cameron at oracle.com
Tue Nov 15 19:42:30 PST 2011
I am just curious how this works on Linux? Do you see the files get
removed when you logout? On Linux, I think the shared memory files
are in /dev/shm. They seem to only persist until the next time a
user logs in when the PulseAudio daemon is restarted.
On 11/ 3/11 07:58 PM, Brian Cameron wrote:
> Oops, I just realized that I didn't attach the debug log attachment.
> Now attached.
> On 11/ 2/11 03:02 PM, Brian Cameron wrote:
>> I notice that PulseAudio version 1.1 seems to leave behind shared
>> memory files when my GNOME session exits, or when I kill the pulseaudio
>> daemon from within my GNOME session.
>> For example, when my session is running I see 3 shared memory files,
>> associated with the following processes:
>> - The PulseAudio daemon
>> - gnome-volume-control-applet
>> - gnome-settings-daemon
>> Upon session logout or when killing the PulseAudio daemon, the shared
>> memory file associated with the PulseAudio daemon gets cleaned up nicely
>> but the two shared memory files associated with clients stay around.
>> I notice that when the pulseaudio daemon restarts it does clean up these
>> stale client files okay. So to test this, I renamed the
>> /usr/bin/pulseaudio daemon to a different name just before killing it
>> from within my GNOME session to prevent it from just restarting and
>> cleaning them up.
>> After killing the PulseAudio daemon, I notice if I then kill the
>> gnome-volume-control-applet or gnome-settings-daemon process, the
>> shared memory files associated with these files still do not get
>> cleaned up.
>> I am not sure, but this may be related to a bug I see:
>> Based on this bug, I see that the xsmp module is supposed to cleanup
>> shared memory files. I do see that the xsmp module is loading fine on
>> my system, and when I enable pulseaudio debug, I see the output in the
>> attached file which seems to indicate that the xsmp module is noticing
>> that the Xserver died and does exit cleanly.
>> So, I am wondering if this is how PulseAudio is intended to work.
>> Maybe PulseAudio is designed to only cleanup the file associated
>> with the daemon on clean exit. Or is there a bug that is causing the
>> PulseAudio client shared memory files to not get cleaned up on
>> PulseAudio exit.
>> This is probably not such a big problem for most PulseAudio users who
>> use single-user desktops/laptops/etc. where there are only a few users
>> who might login and only a few stale files to worry about. However, on
>> multi-user servers, leaving behind these files could create a resource
>> issue if many users login and logout leaving behind unused files.
>> One workaround that I notice is that if you run the
>> "pulseaudio --cleanup-shm" command as root, it does cleanup the files
>> for all users. So, adding this command to the GDM Init script so it
>> gets run each time the login screen is presented will cleanup the stale
>> files. Is this the right way to ensure that stale files never get left
>> Another issue I notice is that each time I kill the pulseaudio deamon
>> it leaves behind another /usr/lib/pulse/gconf-helper process. After
>> killing it a bunch of times I now have over a dozen of these processes
>> Should I file bugs for any of these issues?
>> pulseaudio-discuss mailing list
>> pulseaudio-discuss at lists.freedesktop.org
More information about the pulseaudio-discuss