[SOLVED] /.config and /.cache with Daedalus

User479 · 2023-03-05 16:43:43

Since upgrading from Chimaera to Daedalus I am seeing /.config and /.cache directories.

/.config seems to be used by pulseaudio and will be re-created at boot if it's been removed.

# ls -lR /.config
/.config:
total 4
drwx------ 2 root root 4096 Mar  5 10:02 pulse

/.config/pulse:
total 0
lrwxrwxrwx 1 root root 23 Mar  5 10:02 f3270dcda2b340e98a9808d3dcb611c5-runtime -> /tmp/pulse-PKdhtXMmr18n

/.cache always seems to be empty and gets created at boot (by pulseaudio?) if it's been removed.

# ls -lR /.cache
/.cache:
total 8
drwx------  2 root root 4096 Mar  5 10:02 .
drwxr-xr-x 23 root root 4096 Mar  5 10:02 ..

Is this a Devuan issue or Debian?

Last edited by User479 (2023-03-05 16:44:54)

boughtonp · 2023-03-05 18:27:22

User479 wrote:

Is this a Devuan issue or Debian?

Neither.

It's part of the XDG Base Directory Specification - a bit like the FHS but for user-specific application data.

(It's far from a new thing - Wayback Machine says 2010 for v0.6 - so a little odd you've not noticed it until now.)

The idea is, instead of having a million dotfiles polluting your home directory, you get (by default) three top-level dirs in $HOME (.config, .cache, and .local, each of which you can choose to relocate with environment variables), and within which applications place appropriate config/cache/etc. Makes it easy to backup configuration without also carrying around cache or history or whatever.

More info on Arch wiki's XDG Base Directory page - including the depressingly long list of applications who's developers refuse to support it. :(

-

However, there may be a bug with PulseAudio, because f3270dcda2b340e98a9808d3dcb611c5-runtime -> /tmp/pulse-PKdhtXMmr18n does not look like config, and should probably be using either $XDG_STATE_HOME or $XDG_RUNTIME_DIR instead.

Last edited by boughtonp (2023-03-05 18:33:18)

steve_v · 2023-03-05 18:44:21

boughtonp wrote:

home directory

If you read the OP, you'll notice that there are no home directories involved at all, so XDG_HOME_WHATEVER has nothing to do with anything.
The directories in question are /.config and /.cache - i.e. hidden directories in the system root.

I don't have the machine with me ATM (I'll check later), but IIRC I've seen the same with a chimaera install, and only where pulseaudio is involved.
Whether this is a bug or just expected janky behaviour for potteringware, it is, at the least, extremely ugly.

Last edited by steve_v (2023-03-05 18:46:42)

boughtonp · 2023-03-05 18:58:29

steve_v wrote:

If you read the OP, you'll notice that there are no home directories involved at all

Ah yeah, I misread the / as ~/

so XDG_HOME_WHATEVER has nothing to do with anything.

It may still be relevant, because their default value is usually $HOME/.config - so if $HOME is not set for root user (from then perspective of pulseaudio or wherever XDG_CONFIG_HOME is being set), and no safety checks are made for that situation, then the result would be those directories being created in the wrong location.

So could still be a bug in pulseaudio, or possibly a mis-configuration.

Altoid · 2023-03-05 19:57:13

Hello:

steve_v wrote:

... only where pulseaudio is involved.
... janky behaviour for potteringware ...
... extremely ugly.

Ah ...

boughtonp wrote:

... could still be a bug in pulseaudio ...

Could well be.
No matter, quite easy to fix.

First this:

# apt purge pulseaudio && apt autoclean && apt autoremove

And then this.

Best,

A.

Edit:
Out or curiosity (I purged pulseaudio two/three years ago) I went to see what was up in my / dir.

Seems that purging pulseaudio is not enough: I found /.config/pulse and within it, two files.

One was a 26a708d3d7dc6778fc6ff9f55921b024-runtime file and the other was a cookie file and they were not size nought.

So I left the /.config dir (don't know if it is needed), but eliminated its contents.

Last edited by Altoid (2023-03-05 20:47:54)

User479 · 2023-03-05 21:05:58

Altoid wrote:

No matter, quite easy to fix.
First this:
# apt purge pulseaudio && apt autoclean && apt autoremove

Very good point. I'm using pipewire & wireplumber on my phone & tablet (with mobian bookworm) and it seems to work so I can now just ditch pulseaudio on my destop.

Edit 1: Except the phone and tablet have systemd, of course, and setting up pipewire without that is a bit more complicated.

Edit 2: Actually, the "Alpine solution" turned out to be pretty simple. pipewire-launcher.sh worked without modifications. I use XFCE so it needed the desktop file in ~/.config/autostart/ (with Exec= adapted). I killed pulseaudio, started pipewire, reset the volume control, and it's done.

Last edited by User479 (2023-03-05 22:36:38)

Altoid · 2023-03-05 21:25:33

Hello:

User479 wrote:

... ditch pulseaudio on my destop.

Yes, but do remember to check the link I posted.
You don't want pulseaudio pulled in again by some uncouth package.

~$ cat /etc/apt/preferences.d/avoid_pulseaudio
Package: pulseaudio:*
Pin: version *
Pin-Priority: -1
~$

Best,

A.

steve_v · 2023-03-06 04:23:19

Altoid wrote:

# apt purge pulseaudio && apt autoclean && apt autoremove

Much as I too dislike pulseaudio, if one wants such niceties as on-the-fly switching of bluetooth sinks and whatnot, pure ALSA is a PITA.
While it is still far too complicated IMO, pipewire does at least solve some of the more glaring deficiencies of pulseaudio. Anyone wanting modern convenience features on a laptop or such will probably need one or the other.

User479 wrote:

Edit 1: Except the phone and tablet have systemd, of course, and setting up pipewire without that is a bit more complicated.
Edit 2: Actually, the "Alpine solution" turned out to be pretty simple. pipewire-launcher.sh worked without modifications.

FWIW, I have been playing with pipewire on my (openrc) Gentoo desktop too. Gentoo uses exactly the same pipewire-launcher.sh (anybody's guess who nicked it from who), and while it should work on any distro it does come with one problem - it has no facility for terminating pipewire / wireplumber when the user logs out.
That's not a big deal on a single-user system, nor is it a problem if one has logind set to kill user processes (which in turn breaks the old-school ability to background a task and leave it running after logout though).
If neither of those are true however, it results in stale pipewire processes left running and blocking the sound device when one user logs out and another logs in.

To solve this, I lifted a solution from slackware, namely using daemon to manage the equivalent of systemd "user-units".

The result is 3 autostart files (pipewire, pipewire-pulse, wireplumber), like e.g.:

[Desktop Entry]
Version=1.0
Name=Pipewire
Comment=PipeWire media server
Exec=/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire /usr/bin/pipewire
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
X-GNOME-HiddenUnderSystemd=true
X-KDE-HiddenUnderSystemd=true
X-systemd-skip=true

Zero launcher shell scripts or hacky anti-race sleeps, and the ability to do things like:

$ daemon --list
cdemu
pipewire
pipewire-pulse
pipewire-wireplumber
systembus-notify

As well as stopping, starting, and restarting these user daemons without resorting to pkill and co, giving them pid files, retrying failed starts, and binding to the user's logind session so they exit when they should.

Fractionally more effort (IIRC daemon is in the devuan repos already), but cleaner and more flexible IMO.
Just something to consider, FWIW I strongly suspect we're going to need something like daemon for more than just pipewire in future (I'm also using it for cdemu-daemon and the dbus-notifier part of earlyoom here), as systemd user-units become more popular.

To return to the OT, yes, this /.config and /.cache garbage is created on chimera (default desktop-live/refracta install) as well, and AFAICT the culprit is pulseaudio. Removing pulse will prevent their creation but not remove them if they exist, as they are not tracked by dpkg (for extra nastiness).

Whatever ones opinion of pulseaudio, it shouldn't be creating XDG configuration directories in the system root and so long as devuan is shipping it in the default desktop, I absolutely consider this a bug to be fixed.
I don't have a debian install to compare right now, but my suspicion is that this has to do with pulse assuming systemd and doing broken things when started as root by traditional init (i.e. when XDG_FOO isn't set).

Last edited by steve_v (2023-03-06 04:54:25)

Altoid · 2023-03-06 09:55:57

Hello:

steve_v wrote:

... strongly suspect we're going to need something like daemon ...

... as systemd ~~user-units become more popular.~~ continues to extend its tentacles further and further into Linux. <--- reads better now, I think.

steve_v wrote:

... this /.config and /.cache garbage is created on chimera ...

Not only on chimaera.

I run Devuan Beowulf with a backported kernel.
I suspect it was there since ascii but can't confirm.

steve_v wrote:

... but not remove them if they exist ...
... not tracked by dpkg (for extra nastiness).

So I have seen.

steve_v wrote:

... absolutely consider this a bug to be fixed.

Probably to be reported to Debian.
Don't think it's a Devuan thing, but ...

steve_v wrote:

... has to do with pulse assuming systemd and doing broken things ...

... if that is so, it could/may be due to an incomplete/faulty sanitisation of the pulseaudio package by the Devuan devs.

Thanks for your input.

Best,

A.

User479 · 2023-03-15 20:15:18

For what it's worth, even with pulseaudio purged, an empty /.cache/ is getting created at each boot.

boughtonp · 2023-03-15 20:31:11

So what is result of...

echo "home=$HOME;config=$XDG_CONFIG_HOME;cache=$XDG_CACHE_HOME;"

...when running as root?

Or I guess:

awk -F: '$6~"^/?$"' /etc/passwd

?

Also, have you identified precisely when during boot it gets re-created? i.e. use stat to get the precise time, and compare with files in /var/log to see what happens around the same time.

Last edited by boughtonp (2023-03-15 20:34:48)

Altoid · 2023-03-15 20:36:45

configHello:

User479 wrote:

... pulseaudio purged, an empty /.cache/ is getting created at each boot.

Not here:

~$ uname -a
Linux devuan 5.10.0-0.deb10.16-amd64 #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) x86_64 GNU/Linux
~$

There is no .cache in my /.
All of them live in the /home/user dir.

And this is all the pulse I have:

~$ apt list | grep installed | grep -i pulse*
--- snip ---
debian-pulseaudio-config-override/oldstable,oldstable,now 1.0 all [installed,automatic]
libpulse0/oldstable,now 12.2-4+deb10u1 amd64 [installed,automatic]
libpulse0/oldstable,now 12.2-4+deb10u1 i386 [installed,automatic]
~$

Maybe something else is doing that?

Best,

A.

User479 · 2023-03-16 19:56:52

boughtonp wrote:

So what is result of...

That returns "home=/root;config=;cache=;"

boughtonp wrote:

...use stat to get the precise time

Good idea. During two boots the messages preceeding creation of /.cache were coming from smartd, but I don't know why it would need a cache file. I deleted /.cache and restarted that service, and several others (chrony, opensmtpd, dovecot, rsyslog, cron, dbus), without a new /.cache being created. I'll keep digging. Or maybe not. It's not hurting anything, it's just annoying now that I know about it.

Altoid · 2023-03-16 20:29:09

Hello:

User479 wrote:

I'll keep digging.

Please do.

User479 wrote:

... not hurting anything ...

Not that you know of.

User479 wrote:

... just annoying now that I know about it.

Indeed ...

I think that what is annoying is that something (unknown to you) is creating a .config dir in /.

And from what I have been told, it should not be happening.
Unless at some time your $HOME was set to /.
Which does not seem to be the case.

Granted, it may not be a big deal, but it should not be happening.

My idea of things like these is that they should be investigated and fixed.
If it is a bug or an oversight, it should be squashed/fixed.

All those "won't fix because it is harmless" issues, warnings and/or bug reports which end up being swept under the rug will are not healthy.
I see it as lousy coding and may (eventually) end up causing issues somewhere in the system.

Of course, YMMV.

Best,

A.

boughtonp · 2023-03-16 23:50:05

Altoid wrote:

All those "won't fix because it is harmless" issues, warnings and/or bug reports which end up being swept under the rug will are not healthy.
I see it as lousy coding and may (eventually) end up causing issues somewhere in the system.

Yep, just because there's no obvious harm at the moment doesn't mean there isn't some hidden/future problem.

-

I've just remembered inotify, which can monitor filesystem use - so inotifywait --daemon -e create / should log when a directory is created in root, and inotifywait --daemon -r /.cache will monitor all events within that directory, to see if it's being used - although it doesn't look like inotifywait reports pid/uid information, so the first one probably isn't useful, but if files are being created/removed the names may give a clue as to what it is doing it.

Altoid · 2023-03-16 23:55:53

Hello:

boughtonp wrote:

... because there's no obvious harm at the moment doesn't mean there isn't some hidden/future problem.

Maybe no even harm, obvious or not.
But *something* left behind that could/may, in conjunction with something else, bring up a problem or a situation that could bring up a problem.

boughtonp wrote:

... remembered inotify, which can monitor filesystem use ...

Good idea ...
Please keep us posted.

Thanks for your input.

Best,

A.

ytomino · 2023-09-15 17:21:39

Hello, I'm a newcomer as a Devuan user.
I had a similar situation where /.config or /.cache were created in MX Linux as same as Devuan.
So I thought it might be an init issue since SysVinit is common.

After I read this thread, I took note of the pulseaudio home directory.
The user "pulse"'s home directory is /run/pulse, defined in /etc/passwd.

pulse:x:110:116:PulseAudio daemon,,,:/run/pulse:/usr/sbin/nologin

However, /run/pulse was not exist in my fresh installation.
Other similar daemon home directories are existing, e.g. /run/openntpd, /run/avahi-daemon, or /run/sshd.
grep mkdir /etc/init.d showed that these directories were explicitly mkdir'd, except /run/pulse.

Therefore, I have added an init script that does mkdir /run/pulse && chown pulse:pulse /run/pulse and it seems that /.config is no longer recreated now.
The files are not actually placed in /run/pulse even after I added it, but it may be origin for determining some relative directories.

I hope this will be of some hint.
Thanks.

User479 · 2023-09-16 03:37:54

I had given up on this issue so that's a good find. I don't have a pulse user so my issue is something different but that does indeed shine some light in a direction I hadn't looked. FWIW, /.config isn't being created anymore here but /.cache still is.

amaro · 2023-10-04 04:23:57

Would someone write a step by step tutorial for replacing 'pulse' with 'pipewire' and put it in Documentation section of the forum? That would be nice!

p.s. I often record parts of radio streams with 'audio-recorder' and my concern about purging 'pulse' is if I will still be able to do that with 'pipewire'.

ExposeGlobalistsMadness · 2023-10-05 04:20:03

To install pipewire for X11, the first step, from Debian Pipewire's Github (a Wayland arrangement is mentioned in that link), would be to add their repo, but, you might be better off just tracking Devuan's repos. You can use doas preferably over sudo, but we'll have to omit pipewire-locales, as it is not in Devuan Daedalus' repo at the moment, so instead of...

doas apt install gstreamer1.0-pipewire libpipewire-0.3-{0,dev,modules} libspa-0.2-{bluetooth,dev,jack,modules} pipewire{,-{audio-client-libraries,pulse,bin,jack,alsa,v4l2,libcamera,locales,tests}}

...leave out the locales package if you can do without it, and instead do:

doas apt install gstreamer1.0-pipewire libpipewire-0.3-{0,dev,modules} libspa-0.2-{bluetooth,dev,jack,modules} pipewire{,-{audio-client-libraries,pulse,bin,jack,alsa,v4l2,libcamera,tests}}

You might have some of the above packages already installed in Devuan Daedalus, but apt should pass on those.

Install some 'recommends':

doas apt install libcamera-ipa pipewire-doc

Useful also, including pavucontrol to control audio levels:

doas apt install libpipewire-0.3-modules-x11 pavucontrol
doas apt-get install wireplumber{,-doc} gir1.2-wp-0.4 libwireplumber-0.4-{0,dev}

Make sure that apt responds to the following by saying that xdg-desktop-portal is installed:

apt list --installed | grep xdg-desktop-portal

If not, install it. In my experience, at least in my gtk environment, to avoid some muted videos in a browser for example, it is good to also install a portal backend for xdg-desktop-portal. So depending on whether your desktop environment is Gnome, gtk, KDE, etc, one of the following could be helpful to install:

$ apt-cache search xdg-desktop-portal
xdg-desktop-portal - desktop integration portal for Flatpak and Snap
xdg-desktop-portal-dev - desktop integration portal - development files
xdg-desktop-portal-gnome - GNOME portal backend for xdg-desktop-portal
xdg-desktop-portal-gtk - GTK+/GNOME portal backend for xdg-desktop-portal
xdg-desktop-portal-kde - backend implementation for xdg-desktop-portal using Qt
xdg-desktop-portal-tests - desktop integration portal - automated tests
xdg-desktop-portal-wlr - xdg-desktop-portal backend for wlroots

Get rid of some material, which, in my experience, might not have been purged by apt:

doas apt purge libkf5pulseaudioqt3 libpulsedsp pulseaudio-utils
doas apt autoclean && doas apt autoremove

Next, make pipewire and wireplumber start properly, say, by using the so-called 'Alpine solution' mentioned in post No. 4 above. At the moment, Devuan users might have to prepare scripts, whereas Debian uses systemd services instead. The Alpine solution script, as an autostart file or using a similar text in your ~/.xinitrc file if you have one, might not be the appropriate solution, however, so you might have to investigate. Other similar scripts appear in this forum.

A good tip from Altoid could be to avoid having some other package dragging pulseaudio back on your system. So pin the package off by opening an editor and starting a new file like so:

doas rnano -w /etc/apt/preferences.d/avoid_pulseaudio

Enter the following text in that file. Ctr+S to save and Ctr+x to exit that rnano editor.

Package: pulseaudio:*
Pin: version *
Pin-Priority: -1

Reboot. I hope this helps. If anyone can improve on this, please let us know. Thank you.

EDIT: This upstream Debian pipewire github page may not mention any configuration; pipewire currently seems to fail for me without any. Note that I am only a user, but I am trying to share my successes. So, we'll continue by following Debian 12's wiki section and adapting it to Devuan Daedalus; note particularly:

A notable change compared to Debian 11 is that the configuration directory has been moved from /etc/pipewire/ to /usr/share/pipewire/: you may want to get rid of the former to avoid confusion.

Debian 12's wiki section otherwise tracks the section for Debian 11, so we will update any such references in Debian's 11's wiki section to /usr/share/pipewire/ .

Also, instead of applying the systemd or perhaps also pactl directives, we'll rely as stated earlier on running pipewire and wireplumber either from .xinitrc or in autostart batch files (or perhaps in .xsessionrc). The wiki also uses systemctl commands (a "daemonless "systemctl" command to manage services without systemd", according to apt), but in my experience, perhaps one might be able to do without installing that.

The wiki recommends applying instructions of "all" three sections, yet somehow there is also a fourth section -- PulseAudio ("replacing PulseAudio completely"), Alsa, JACK and bluetooth:

The three instructional sections below are independent of each other, but you are still highly recommended to use PipeWire to replace all of them if you intend to replace any of it, for the best integration between different applications.

At any rate, bluetooth seems to take care of itself, as no configuration action is mentioned; we had already installed libspa-0.2-bluetooth earlier.

For PulseAudio, which is being replaced:

doas mkdir /usr/share/pipewire/media-session.d
doas touch /usr/share/pipewire/media-session.d/with-pulseaudio

As mentioned earlier, we'll pass over the commands to create services ("Create a pipewire-pulse service by copying the example files"); we'll also pass over the guide to run wireplumber as root.

Next, for Alsa:

doas touch /usr/share/pipewire/media-session.d/with-alsa

Our master guide (Debian 11 as a guide for Debian 12) then instructs: # cp /usr/share/doc/pipewire/examples/alsa.conf.d/99-pipewire-default.conf /etc/alsa/conf.d/ . As there appears to be no Alsa configuration example folder in Daedalus (/usr/share/doc/pipewire/examples/alsa.conf.d/), hopefully there is no Alsa configuration file needed.

Next, for JACK, and remembering to use /usr/share/pipewire instead of /etc/pipewire:

doas touch /usr/share/pipewire/media-session.d/with-jack

There is one example configuration file for JACK, and it's not yet at the target folder (/etc/ld.so.conf.d/), so try copying it over:

doas cp /usr/share/doc/pipewire/examples/ld.so.conf.d/pipewire-jack-*.conf /etc/ld.so.conf.d/

Create links and cache:

doas ldconfig

Now launch pavucontrol aka PulseAudio Volume Control (although it is hardly dependent on PulseAudio in Devuan), and under 'Configuration', set one or more profiles to 'Pro audio'. Pipewire runs fine now for me.

Note: As an alternative to being inspired by the 'Alpine solution' above, I am now starting up packages in .xinitrc as suggested elsewhere in this forum, but adding 2-4 second delays. Try placing the instructions high up in .xinitrc (or perhaps .xsessionrc), before any audio package command such as amixer; perhaps those may need to be delayed similarly.

pipewire &
( sleep 2 ; pipewire-pulse) &
( sleep 4 ; wireplumber) &

I hope this helps.

Last edited by ExposeGlobalistsMadness (2023-10-08 16:48:53)

The officially official Devuan Forum!

#1 2023-03-05 16:43:43

[SOLVED] /.config and /.cache with Daedalus

#2 2023-03-05 18:27:22

Re: [SOLVED] /.config and /.cache with Daedalus

#3 2023-03-05 18:44:21

Re: [SOLVED] /.config and /.cache with Daedalus

#4 2023-03-05 18:58:29

Re: [SOLVED] /.config and /.cache with Daedalus

#5 2023-03-05 19:57:13

Re: [SOLVED] /.config and /.cache with Daedalus

#6 2023-03-05 21:05:58

Re: [SOLVED] /.config and /.cache with Daedalus

#7 2023-03-05 21:25:33

Re: [SOLVED] /.config and /.cache with Daedalus

#8 2023-03-06 04:23:19

Re: [SOLVED] /.config and /.cache with Daedalus

#9 2023-03-06 09:55:57

Re: [SOLVED] /.config and /.cache with Daedalus

#10 2023-03-15 20:15:18

Re: [SOLVED] /.config and /.cache with Daedalus

#11 2023-03-15 20:31:11

Re: [SOLVED] /.config and /.cache with Daedalus

#12 2023-03-15 20:36:45

Re: [SOLVED] /.config and /.cache with Daedalus

#13 2023-03-16 19:56:52

Re: [SOLVED] /.config and /.cache with Daedalus

#14 2023-03-16 20:29:09

Re: [SOLVED] /.config and /.cache with Daedalus

#15 2023-03-16 23:50:05

Re: [SOLVED] /.config and /.cache with Daedalus

#16 2023-03-16 23:55:53

Re: [SOLVED] /.config and /.cache with Daedalus

#17 2023-09-15 17:21:39

Re: [SOLVED] /.config and /.cache with Daedalus

#18 2023-09-16 03:37:54

Re: [SOLVED] /.config and /.cache with Daedalus

#19 2023-10-04 04:23:57

Re: [SOLVED] /.config and /.cache with Daedalus

#20 2023-10-05 04:20:03

Re: [SOLVED] /.config and /.cache with Daedalus

Board footer