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

[Felipe Sateler]

On Fri, Oct 13, 2017 at 8:30 AM, Michael Biebl <biebl at debian.org> wrote:
> Control: tags -1 moreinfo
>
> On Fri, 13 Oct 2017 07:21:18 -0400 Antonio Russo
> <antonio.e.russo at gmail.com> 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