Your message dated Mon, 28 Apr 2014 18:37:30 -0400 with message-id <CAAfdZj9f=549imtrvjxysbej5heuzasozz+521ts2nbcqk9...@mail.gmail.com> and subject line Fixed in alsa-utils 1.0.27.2-1 has caused the Debian Bug report #742388, regarding libpulse0: spurious files .pulse and .pulse-cookie in /root directory to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 742388: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742388 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: libpulse0 Version: 2.0-6.1 Severity: normal Tags: patch I noticed that the following files and directory keep appearing in my /root directory even after I remove them and even if root is not logged in: /root/.pulse-cookie /root/.pulse /root/.pulse/blahblah-runtime -> /tmp/pulse-blah In particular, they appear during system boot, and when hot-plugging a (USB) audio device. The latter obviously made udev suspicious, and debugging revealed that it calls "alsactl restore" with HOME unset. Then alsactl, more precisely libpulse0 which it uses, in function pa_get_home_dir(), finds that HOME is not set and retrieves the root user's home directory (/root) via getpwuid(). AFAIK that's wrong! /root is meant for root-as-a-user, i.e. when logged in as root, not for daemons which run with root permissions. It also doesn't seem to make much sense: These files are apparently there to find some data for pulse. But pulse runs per-user (and its home page severly warns against running in system mode), so these files under /root are probably never seen and used at all. Maybe the core of the problem is that different developers are unclear about the role of alsactl and/or libpulse0. (a) Their own developers may think they're user programs (so HOME should always be set), but (b) udev developers apparently think it's OK to call them from a daemon (so HOME is not set). If (a) is correct, udev must not call alsactl without HOME set. If (b) is correct, libpulse0 must accept when HOME is not set, and not try to set it via getpwuid(), and in this case not create those files and directory at all (if they're pointless anyway) or put them somewhere under /run. Work-around: Even though I'd tend to think (b) is correct, a quick fix is easier with (a), so I go with that for now. (In the end it must be sorted out between those developers.) Instead of setting HOME, this patch sets USERPROFILE (for a more localized change), which pa_get_home_dir() checks after HOME and before using getpwuid(): --- 90-alsa-restore.rules +++ 90-alsa-restore.rules @@ -1,2 +1,2 @@ ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS=="card*", \ - TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl restore $attr{number}" + TEST=="/usr/sbin/alsactl", ENV{USERPROFILE}="/run/pulseaudio", RUN+="/usr/sbin/alsactl restore $attr{number}" Note: With this patch, it actually doesn't create those files at all because /run/pulseaudio doesn't exist. That seems fine to me, since these files apparently serve no purpose anyway, see above. If you want them, just create this directory in some init or wrapper script. (I've tested both cases.) -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: i386 (i686)
--- End Message ---
--- Begin Message ---This was fixed in alsa-utils by a similar approach. -- Saludos, Felipe Sateler
--- End Message ---
