When added to the boot runlevel as suggested by alsa-utils ebuild, alsasound init script cause creation of this files and dirs: # find /.pulse* -exec ls -ld '{}' \+ drwx------ 2 root root 4096 окт. 18 23:37 /.pulse lrwxrwxrwx 1 root root 23 окт. 18 23:37 /.pulse/ae62d786a6165c6c0743aa3a00000010-runtime -> /tmp/pulse-2L9K88eMlGn7 -rw------- 1 root root 256 окт. 18 23:37 /.pulse-cookie I think this is due to a miss of HOME env variable at the time this script runs. If I manually restart alsasound then it creates/updates this files in "/root" dir. $ emerge -pv media-sound/alsa-utils media-sound/pulseaudio These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-sound/alsa-utils-1.0.25-r1 USE="nls -doc -minimal (-selinux)" 0 kB [ebuild R ~] media-sound/pulseaudio-2.1-r1 USE="X alsa asyncns avahi bluetooth caps dbus gdbm glib gnome gtk ipv6 libsamplerate realtime ssl tcpd udev webrtc-aec -doc -equalizer -jack -lirc -orc (-oss) (-system-wide) -systemd -test -xen" 0 kB Total: 2 packages (2 reinstalls), Size of downloads: 0 kB Reproducible: Always
Created attachment 326886 [details, diff] alsasound.initd-r5.patch This patch fixes this issue for me.
Created attachment 329334 [details, diff] alsasound.initd-r5.patch Similar workaround but using temporary dir as a home
Created attachment 329356 [details, diff] alsasound.initd-r5.patch
Created attachment 330714 [details, diff] alsasound.initd-r5.patch
I can confirm this is still an issue with media-sound/alsa-utils-1.0.27.2 and media-sound/pulseaudio-4.0, though the directories are slightly different because of the more recent pulseaudio. When started from the boot run-level, alsasound creates "/.config/pulse". When restarting alsasound manually, it creates "/root/.config/pulse".
Restoring the alsa mixer levels at such an early stage in the boot process is not a good idea in my opinion. Especially when alsa-utils is compiled with +pulseaudio, invoking alsactl store/restore will create the .pulse files on whatever location $HOME ist set. I run /usr/sbin/alsactl -f ${HOME}/.asound.state -I store/restore as user when i login/logout to/from the Desktop (in my case KDE). This way, i have no problems with .pulse files spread across / or /root.
Interesting that there is no problems with systemd. alsactl does not create any pulse files when started by this service: $ cat /usr/lib/systemd/system/basic.target.wants/alsa-restore.service # # Note that two different ALSA card state management schemes exist and they # can be switched using a file exist check - /etc/alsa/state-daemon.conf . # [Unit] Description=Restore Sound Card State ConditionPathExists=!/etc/alsa/state-daemon.conf DefaultDependencies=no After=alsa-state.service Before=shutdown.target Conflicts=shutdown.target [Service] Type=oneshot ExecStart=-/usr/sbin/alsactl restore StandardOutput=syslog
(In reply to Alexander Tsoy from comment #7) > Interesting that there is no problems with systemd. alsactl does not create > any pulse files when started by this service: > > $ cat /usr/lib/systemd/system/basic.target.wants/alsa-restore.service > # > # Note that two different ALSA card state management schemes exist and they > # can be switched using a file exist check - /etc/alsa/state-daemon.conf . > # > > [Unit] > Description=Restore Sound Card State > ConditionPathExists=!/etc/alsa/state-daemon.conf > DefaultDependencies=no > After=alsa-state.service > Before=shutdown.target > Conflicts=shutdown.target > > [Service] > Type=oneshot > ExecStart=-/usr/sbin/alsactl restore > StandardOutput=syslog Are you sure there are no .pulse files in /root? I guess that $HOME ist set somehow when this systemd service is executed, as i cannot see any differences to how the openrc init script handles store/restore. Do you use systemd, and does the file /etc/alsa/state-daemon.conf exist on your system?
(In reply to Andreas Hermann from comment #8) Oh.. I checked this on a wrong system that have no sound cards connected. :) Yes, with systemd these files get created in /root/.
this is still issue. Patch created by Alexander Tsoy fixes it. Please include it
added as alsasound.initd-r6 and alsa-utils-1.0.28 (bug 513670) uses it.