Bug#878401: [systemd] Dependency on /tmp not correctly stated for some sound.target (or /tmp/pulse-* shows up underneath my /tmp mount)
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)
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)
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)
On Fri, Oct 13, 2017 at 9:58 AM, Antonio Russowrote: > 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)
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)
On Fri, Oct 13, 2017 at 8:30 AM, Michael Bieblwrote: > 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)
Control: tags -1 moreinfo On Fri, 13 Oct 2017 07:21:18 -0400 Antonio Russowrote: > 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)
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