Jörg-Volker Peetz wrote on 16/12/2019 20:32: > Greg Wooledge wrote on 16/12/2019 17:29: >> On Sat, Dec 14, 2019 at 10:04:34AM +0100, Jörg-Volker Peetz wrote: >>> $ dpkg -S /pulse >>> dpkg-query: no path found matching pattern /pulse >>> >>> fails to give any clue. >>> The directory is generated at boot-time. But I wasn't able to find any hint >>> in >>> systemd or udev conf-files. >> >> Well, the first thing I would try would be "grep -r /pulse /etc". >> And if that fails, "grep -r /pulse /lib/systemd". > > Did that, also > > $ grep -rI pulse /lib/udev > > to no avail. >> >> If *those* both fail... well, I might be crazy enough to try removing >> the offending directory, doing "chattr +i /", then rebooting, and seeing >> who complains when they can't create the /pulse directory. Only on a >> system where I have local hardware access, of course -- not a remote. >> >> Do not forget to remove the immutable bit after your test is complete. >> >> And as a wise reader already said, it's probably pulseaudio. Meaning, >> you might be able to test without rebooting, by stopping pulseaudio, >> removing the directory, and starting pulseaudio, to see if it gets >> recreated. > > The /pulse directory is created at boot-time. The pulseaudio process is > started > at login on this system. Also, pulseaudio continues to work after removal of > /pulse which is always an empty directory. It has uid 0 and gid 0 an is not > readable for group or others. > The only relevant script at boot-time on my system seems to be from alsa-utils. But at the moment I'm lost how this interacts with pulseaudio. At the same time the /pulse directory is created, there is created an also empty /run/alsa/runtime/pulse directory. Any idea, anybody?
> Does anybody else see such a /pulse directory? Regards, Jörg.
