You are not logged in.
Pages: 1
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)
Offline
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)
3.1415P265E589T932E846R64338
Online
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)
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Offline
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.
3.1415P265E589T932E846R64338
Online
Hello:
... only where pulseaudio is involved.
... janky behaviour for potteringware ...
... extremely ugly.
Ah ...
... 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)
Offline
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)
Offline
Hello:
... 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.
Offline
# 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.
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)
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Offline
Hello:
... 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.
... 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.
... but not remove them if they exist ...
... not tracked by dpkg (for extra nastiness).
So I have seen.
... absolutely consider this a bug to be fixed.
Probably to be reported to Debian.
Don't think it's a Devuan thing, but ...
... 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.
Offline
For what it's worth, even with pulseaudio purged, an empty /.cache/ is getting created at each boot.
Offline
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)
3.1415P265E589T932E846R64338
Online
configHello:
... 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.
Offline
So what is result of...
That returns "home=/root;config=;cache=;"
...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.
Offline
Hello:
I'll keep digging.
Please do.
... not hurting anything ...
Not that you know of.
... 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.
Offline
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.
3.1415P265E589T932E846R64338
Online
Hello:
... 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.
... remembered inotify, which can monitor filesystem use ...
Good idea ...
Please keep us posted.
Thanks for your input.
Best,
A.
Offline
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.
Offline
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.
Offline
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'.
Offline
Pages: 1