Summary: | media-sound/alsa-utils[pulseaudio]: alsasound init.d script generates pulse state files in / | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexander Tsoy <alexander> |
Component: | Current packages | Assignee: | Gentoo ALSA team <alsa-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | moses.matthewl, phobosk, rei4dan |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
alsasound.initd-r5.patch
alsasound.initd-r5.patch alsasound.initd-r5.patch alsasound.initd-r5.patch |
Description
Alexander Tsoy
2012-10-18 20:00:16 UTC
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. |