[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 · Today 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'.

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 Today 04:23:57

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

Board footer