Your message dated Tue, 25 Sep 2018 08:25:17 +0200 with message-id <20180925062517.ohhor7mk6sx2u...@toy.home.lxtec.de> and subject line Re: [Pkg-alsa-devel] Bug#675857: pulseaudio creates .config/pulse in a root directory has caused the Debian Bug report #675857, regarding /etc/init.d/alsa-utils creates /.config/pulse under sysvinit 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 ow...@bugs.debian.org immediately.) -- 675857: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675857 Debian Bug Tracking System Contact ow...@bugs.debian.org 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 ---Hi gents, * Niels Thykier <ni...@thykier.net> [2018-09-24 06:24 +0000]: [...] > Hi, > > I added a MR on salsa for this issue[1] fixing a missing call to > alsactl. I could not see any (direct) calls to aumix, so these are not > covered. There are some calls to amixer but it does not seem to create > .config if missing despite looking for it. > > Admittedly, Daniel's solution of simply setting HOME is probably easier > to maintain in the long run and less like to "miss" a call. Just for the record: In stable we have 1.1.3-1 which doesn't fit to this bug. Debian alsa pkg maintainers won't fix any older version than that. So I close this bug hereby. BTW stable can run sysvinit very well. Elimar -- Never make anything simple and efficient when a way can be found to make it complex and wonderful ;-)
--- End Message ---
