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

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers


Processed: Re: 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 Debian Bug Tracking System
Processing control commands:

> reassign -1 alsa-utils
Bug #878401 [systemd] [systemd] Dependency on /tmp not correctly stated for 
some sound.target (or /tmp/pulse-* shows up underneath my /tmp mount)
Bug reassigned from package 'systemd' to 'alsa-utils'.
No longer marked as found in versions systemd/234-3.
Ignoring request to alter fixed versions of bug #878401 to the same values 
previously set

-- 
878401: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878401
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers


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

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers


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

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers


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

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers


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

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers


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
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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 ---

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers