Bug#878401: [systemd] Dependency on /tmp not correctly stated for some sound.target (or /tmp/pulse-* shows up underneath my /tmp mount)

2019-09-22 Thread Dominick Grift
On Sun, Sep 22, 2019 at 05:40:14PM +0200, Dominick Grift wrote:
> Setting PULSE_RUNTIME_PATH did not do it for me.
> 
> I borrowed the following from Fedora, and did:
> 
> 1. /etc/udev/rules.d/90-alsa-restore.rules:
> 
> ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", 
> GOTO="alsa_restore_go"
> GOTO="alsa_restore_end"
> 
> LABEL="alsa_restore_go"
> TEST!="/etc/alsa/state-daemon.conf", RUN+="/usr/sbin/alsactl -E 
> HOME=/run/alsa -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf 
> --initfile=/usr/share/alsa/init/00main restore /dev/$name"
> TEST=="/etc/alsa/state-daemon.conf", RUN+="/usr/sbin/alsactl -E 
> HOME=/run/alsa -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf 
> --initfile=/usr/share/alsa/init/00main nrestore /dev/$name"
> 
> LABEL="alsa_restore_end"
> 
> 2. /etc/systemd/system/alsa-state.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=Manage Sound Card State (restore and store)
> Documentation=man:alsactl(1)
> ConditionPathExists=/etc/alsa/state-daemon.conf
> 
> [Service]
> Type=simple
> ExecStart=-/usr/sbin/alsactl -E HOME=/run/alsa -E 
> ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf 
> --initfile=/usr/share/alsa/init/00main -s -n 19 -c rdaemon
> ExecStop=-/usr/sbin/alsactl -E HOME=/run/alsa -s kill save_and_quit
> 
> 3. /etc/systemd/system/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=Save/Restore Sound Card State
> Documentation=man:alsactl(1)
> ConditionPathExists=!/etc/alsa/state-daemon.conf
> 
> [Service]
> Type=oneshot
> RemainAfterExit=true
> ExecStart=-/usr/sbin/alsactl -E HOME=/run/alsa -E 
> ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf 
> --initfile=/usr/share/alsa/init/00main restore
> ExecStop=-/usr/sbin/alsactl -E HOME=/run/alsa -E 
> ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf store
> StandardOutput=syslog
> 
> 
> ... seems to work

Oh and:

4. cat /etc/alsa/alsactl.conf:

ctl.hw {
@args [ CARD ]
@args.CARD {
type string
default "0"
}
type hw
card $CARD
}

5. cat /etc/alsa/state-daemon.conf:

# Remove this file to disable the alsactl daemon mode


signature.asc
Description: PGP signature


Bug#878401: [systemd] Dependency on /tmp not correctly stated for some sound.target (or /tmp/pulse-* shows up underneath my /tmp mount)

2019-09-22 Thread Dominick Grift
Setting PULSE_RUNTIME_PATH did not do it for me.

I borrowed the following from Fedora, and did:

1. /etc/udev/rules.d/90-alsa-restore.rules:

ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", 
GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

LABEL="alsa_restore_go"
TEST!="/etc/alsa/state-daemon.conf", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa 
-E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf 
--initfile=/usr/share/alsa/init/00main restore /dev/$name"
TEST=="/etc/alsa/state-daemon.conf", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa 
-E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf 
--initfile=/usr/share/alsa/init/00main nrestore /dev/$name"

LABEL="alsa_restore_end"

2. /etc/systemd/system/alsa-state.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=Manage Sound Card State (restore and store)
Documentation=man:alsactl(1)
ConditionPathExists=/etc/alsa/state-daemon.conf

[Service]
Type=simple
ExecStart=-/usr/sbin/alsactl -E HOME=/run/alsa -E 
ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/usr/share/alsa/init/00main 
-s -n 19 -c rdaemon
ExecStop=-/usr/sbin/alsactl -E HOME=/run/alsa -s kill save_and_quit

3. /etc/systemd/system/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=Save/Restore Sound Card State
Documentation=man:alsactl(1)
ConditionPathExists=!/etc/alsa/state-daemon.conf

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=-/usr/sbin/alsactl -E HOME=/run/alsa -E 
ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/usr/share/alsa/init/00main 
restore
ExecStop=-/usr/sbin/alsactl -E HOME=/run/alsa -E 
ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf store
StandardOutput=syslog


... seems to work

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift


signature.asc
Description: PGP signature


Bug#878401: [systemd] Dependency on /tmp not correctly stated for some sound.target (or /tmp/pulse-* shows up underneath my /tmp mount)

2017-10-13 Thread Antonio Russo
Control: reassign -1 alsa-utils

The same changes should also be applied to
/lib/systemd/system/alsa-restore.service
/etc/init.d/alsa-utils



Bug#561777: Bug#878401: [systemd] Dependency on /tmp not correctly stated for some sound.target (or /tmp/pulse-* shows up underneath my /tmp mount)

2017-10-13 Thread Antonio Russo
On 10/13/17 09:27, Felipe Sateler wrote:
> On Fri, Oct 13, 2017 at 9:58 AM, Antonio Russo
>  wrote:
>> On 10/13/17 07:30, Michael Biebl wrote:
>>>
>>> That seems like the wrong approach. sound.target does not have any
>>> dependencies on /tmp.
>>> If anything, it's pulseaudio which should ensure that /tmp is mounted.
>>
>> I agree, wholeheartedly. But getting this directory out of /tmp has
>> been a bug for 7 years [1].
> 
> Well, it's not usually a grave problem to have an empty dir in /tmp,
> so nobody gave it much priority

Yeah, I bumped my head on this because zfs mount will not, by
default, mount on top of a nonempty directory.

Honestly, I wouldn't have noticed otherwise.

> 
> I think I have found the culprit. It is pulseaudio, because there is
> no suitable runtime dir, so it creates its own runtime dir in /tmp.
> Please try the following change: edit
> /lib/udev/rules.d/90-alsa-restore.rules , and change the alsactl lines
> to add a new flag:
> 
> 
> /usr/sbin/alsactl -E HOME=/run/alsa -E PULSE_RUNTIME_PATH=/run/alsa/runtime 
> restore $attr{device/number}
> 
> (and the same for the nrestore command).
> 

Yep, that fixes it. Should this be reassigned to alsa-utils, then? This
probably also resolves pulseaudio bug 561777.

Antonio Russo



Bug#878401: [systemd] Dependency on /tmp not correctly stated for some sound.target (or /tmp/pulse-* shows up underneath my /tmp mount)

2017-10-13 Thread Felipe Sateler
On Fri, Oct 13, 2017 at 9:58 AM, Antonio Russo
 wrote:
> On 10/13/17 07:30, Michael Biebl wrote:
>>
>> That seems like the wrong approach. sound.target does not have any
>> dependencies on /tmp.
>> If anything, it's pulseaudio which should ensure that /tmp is mounted.
>
> I agree, wholeheartedly. But getting this directory out of /tmp has
> been a bug for 7 years [1].

Well, it's not usually a grave problem to have an empty dir in /tmp,
so nobody gave it much priority

>
>>
>> I am confused though: Are you suggesteting that pulseaudio is started by
>> sound.target?
>> pulseaudio.service is supposed to be a systemd user service so this
>> doesn't really make sense.
>
> I don't know why a pulse directory is being created, but its right after
> sound.target and after sound devices start getting loaded by the kernel.
> Maybe there's some weird udev hook I should look for? Everything in
>
> /lib/udev/rules.d
>
> that has the word "pulse" in it, only seems to have environment variables
> being set in them.
>
> I will say that on other machines I'm looking at, the pulse directory is
> created much later on, relative to the beginning of the systemd log.

I think I have found the culprit. It is pulseaudio, because there is
no suitable runtime dir, so it creates its own runtime dir in /tmp.
Please try the following change: edit
/lib/udev/rules.d/90-alsa-restore.rules , and change the alsactl lines
to add a new flag:


/usr/sbin/alsactl -E HOME=/run/alsa -E PULSE_RUNTIME_PATH=/run/alsa/runtime 
restore $attr{device/number}

(and the same for the nrestore command).

-- 

Saludos,
Felipe Sateler



Bug#878401: [systemd] Dependency on /tmp not correctly stated for some sound.target (or /tmp/pulse-* shows up underneath my /tmp mount)

2017-10-13 Thread Antonio Russo
On 10/13/17 07:30, Michael Biebl wrote:
> 
> That seems like the wrong approach. sound.target does not have any
> dependencies on /tmp.
> If anything, it's pulseaudio which should ensure that /tmp is mounted.

I agree, wholeheartedly. But getting this directory out of /tmp has
been a bug for 7 years [1].

> 
> I am confused though: Are you suggesteting that pulseaudio is started by
> sound.target?
> pulseaudio.service is supposed to be a systemd user service so this
> doesn't really make sense.

I don't know why a pulse directory is being created, but its right after
sound.target and after sound devices start getting loaded by the kernel.
Maybe there's some weird udev hook I should look for? Everything in

/lib/udev/rules.d

that has the word "pulse" in it, only seems to have environment variables
being set in them.

I will say that on other machines I'm looking at, the pulse directory is
created much later on, relative to the beginning of the systemd log.

***This particular machine has to wait around a long time for udev to settle,
(for a zpool import to start and finish). Maybe there's some race that
just usually isn't a problem otherwise?***

> Is it possible that pulseaudio is started via other means which are not
> under systemd's control?

I sent you journalctl -b in a private email. If there's anywhere else you
can think of looking, I'm open to suggestions.

> 
> Michael
> 

When I get a chance, I'll try to add a dependency on /tmp to
sound.target to see if that delays the creation of /tmp/pulse-* .

Antonio

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561777



Bug#878401: [systemd] Dependency on /tmp not correctly stated for some sound.target (or /tmp/pulse-* shows up underneath my /tmp mount)

2017-10-13 Thread Felipe Sateler
On Fri, Oct 13, 2017 at 8:30 AM, Michael Biebl  wrote:
> Control: tags -1 moreinfo
>
> On Fri, 13 Oct 2017 07:21:18 -0400 Antonio Russo
>  wrote:
>> Package: systemd
>> Version: 234-3
>> Severity: normal
>>
>> --- Please enter the report below this line. ---
>> I mount a filesystem over /tmp in /etc/fstab, but if I take a peek 
>> underneath,
>>
>> > # mount --bind / /mnt
>> > # cd /mnt
>> > # ls -la
>> > total 16
>> > drwxrwxrwt  4 root root 4096 Oct 13 01:46 ./
>> > drwxr-xr-x 24 root root 4096 Oct 12 23:30 ../
>> > drwx--  2 root root 4096 Oct 13 01:46 pulse-2L9K88eMlGn7/
>> > drwx--  2 root root 4096 Oct 13 01:38 pulse-PKdhtXMmr18n/
>>
>> Triangulating with journalctl -b (and stat to get the right microsecond)
>> shows these being created right after the first soundcard is processed
>> by the kernel.
>>
>> It seems that sound.target should depend on /tmp mount, at least
>> until pulse stops putting this directory in /tmp.
>>
>
> That seems like the wrong approach. sound.target does not have any
> dependencies on /tmp.
> If anything, it's pulseaudio which should ensure that /tmp is mounted.
>
> I am confused though: Are you suggesteting that pulseaudio is started by
> sound.target?
> pulseaudio.service is supposed to be a systemd user service so this
> doesn't really make sense.
>
> Is it possible that pulseaudio is started via other means which are not
> under systemd's control?

This might be caused by the alsa units. The pulse plugin might be
attempting to connect to pulseaudio, but it's not running yet.

Could you attach the relevant journalctl output to determine this?


-- 

Saludos,
Felipe Sateler



Bug#878401: [systemd] Dependency on /tmp not correctly stated for some sound.target (or /tmp/pulse-* shows up underneath my /tmp mount)

2017-10-13 Thread Michael Biebl
Control: tags -1 moreinfo

On Fri, 13 Oct 2017 07:21:18 -0400 Antonio Russo
 wrote:
> Package: systemd
> Version: 234-3
> Severity: normal
> 
> --- Please enter the report below this line. ---
> I mount a filesystem over /tmp in /etc/fstab, but if I take a peek underneath,
> 
> > # mount --bind / /mnt
> > # cd /mnt
> > # ls -la
> > total 16
> > drwxrwxrwt  4 root root 4096 Oct 13 01:46 ./
> > drwxr-xr-x 24 root root 4096 Oct 12 23:30 ../
> > drwx--  2 root root 4096 Oct 13 01:46 pulse-2L9K88eMlGn7/
> > drwx--  2 root root 4096 Oct 13 01:38 pulse-PKdhtXMmr18n/
> 
> Triangulating with journalctl -b (and stat to get the right microsecond)
> shows these being created right after the first soundcard is processed
> by the kernel.
> 
> It seems that sound.target should depend on /tmp mount, at least
> until pulse stops putting this directory in /tmp.
> 

That seems like the wrong approach. sound.target does not have any
dependencies on /tmp.
If anything, it's pulseaudio which should ensure that /tmp is mounted.

I am confused though: Are you suggesteting that pulseaudio is started by
sound.target?
pulseaudio.service is supposed to be a systemd user service so this
doesn't really make sense.

Is it possible that pulseaudio is started via other means which are not
under systemd's control?

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#878401: [systemd] Dependency on /tmp not correctly stated for some sound.target (or /tmp/pulse-* shows up underneath my /tmp mount)

2017-10-13 Thread Antonio Russo
Package: systemd
Version: 234-3
Severity: normal

--- Please enter the report below this line. ---
I mount a filesystem over /tmp in /etc/fstab, but if I take a peek underneath,

> # mount --bind / /mnt
> # cd /mnt
> # ls -la
> total 16
> drwxrwxrwt  4 root root 4096 Oct 13 01:46 ./
> drwxr-xr-x 24 root root 4096 Oct 12 23:30 ../
> drwx--  2 root root 4096 Oct 13 01:46 pulse-2L9K88eMlGn7/
> drwx--  2 root root 4096 Oct 13 01:38 pulse-PKdhtXMmr18n/

Triangulating with journalctl -b (and stat to get the right microsecond)
shows these being created right after the first soundcard is processed
by the kernel.

It seems that sound.target should depend on /tmp mount, at least
until pulse stops putting this directory in /tmp.

--- System information. ---
Architecture: Kernel:   Linux 4.13.0-1-amd64

Debian Release: buster/sid
   300 testing ftp.us.debian.org   250 unstable
ftp.us.debian.org   200 experimentalftp.us.debian.org
--- Package information. ---
Depends  (Version) | Installed
==-+-
libacl1  (>= 2.2.51-8) | libapparmor1 
(>= 2.9.0-3+exp2) | libaudit1 (>= 1:2.2.1)
| libblkid1  (>= 2.19.1) | libc6
(>= 2.17) | libcap2(>=
1:2.10) | libcryptsetup4(>= 2:1.4.3) | libgcrypt20  
   (>= 1.7.0) | libgpg-error0
(>= 1.14) | libidn11 (>= 1.13) | libip4tc0  
(>= 1.6.0+snapshot20161117) | libkmod2
(>= 5~) | liblz4-1 (>= 0.0~r130) | liblzma5 
 (>= 5.1.1alpha+20120614) | libmount1
  (>= 2.26.2) | libpam0g (>= 0.99.7.1) | libseccomp2
 (>= 2.3.1) | libselinux1
 (>= 2.1.9) | libsystemd0  (= 234-3) | util-linux   
  (>= 2.27.1) | mount
(>= 2.26) | adduser| procps 
|

Package Status   (Version) | Installed
==-+-===
udev   | 234-3
dracut | initramfs-tools| 0.130


Recommends  (Version) | Installed
=-+-===
libpam-systemd| 234-3
dbus  | 1.11.20-1


Suggests   (Version) | Installed
-+-===
systemd-container| policykit-1  | 0.105-18



--- Output from package bug script ---