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. Brian 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. > > Brian > > > 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: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=444684 >> >> 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 >> behind? >> >> 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 >> running. >> >> Should I file bugs for any of these issues? >> >> Brian >> >> _______________________________________________ >> pulseaudio-discuss mailing list >> pulseaudio-discuss at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss >
