Where to set XDG_CACHE_HOME?

[Duncan]

Marek Greško posted on Sat, 28 Feb 2026 10:54:53 +0000 as excerpted:

> I am trying to find out where to set XDG_CACHE_HOME in Fedora 43 for
> plasma correctly.
> 
> I have setup an environment where users have home directories on a nfs
> share. I wanted to create local directory for XDG_CACHE_HOME. So I
> created a file /etc/profile.d/nss-cache.sh containing
> 
> #!/bin/bash
> 
> CACHEDIR="/home/local/${USER}"
> 
> if [[ "${HOME}" =~ ^/home/domain/.* ]]; then export
> NSS_SDB_USE_CACHE=yes if [ -w "${CACHEDIR}" ]; then export
> XDG_CACHE_HOME="${CACHEDIR}/.cache" fi fi
> 
> But it was not doing anything. Then I found out it works when I run some
> applications from the terminal, so I realized plasma does not use
> /etc/profile.d. Thereafter I tried to copy the file into the
> /etc/xdg/plasma-workspace/env/ directory. It mostly works. But I get the
> mesa_shader_cache directory created in the $HOME/.cache and also in the
> $XDG_CACHE_HOME. I think this is because the directory is created prior
> to runing the script in /etc/xdg/plasma-workspace/env, and then aft4er
> loading the file the directory is created again.
> 
> Do you have any clue where should be the script run from to be started
> soon enough I do not have the $HOME/.cache/mesa_shader_cache created?

So like RJVBertin I have my own sort of customized solution that works for 
me and probably won't for you, but perhaps it'll give you another idea to 
think about trying to modify so it /does/ work for you, so I'll post it, 
but see below for a second possible solution (that I know less about but 
that may have a better chance of actually working for you) as well.

Here, I do CLI logins without any *DM installed at all, so the login 
automatically has the benefit of the full profile and bashrc 
initialization (including setting the various XDG_* variables as 
appropriate).  Then if I wish to start plasma, from my usual CLI shell 
prompt I run a script that does any additional kde/plasma specific setup 
before invoking:

/usr/libexec/plasma-dbus-run-session-if-needed /usr/bin/startplasma-
wayland

As suggested by the filenames, plasma-dbus-run-session-if-needed starts a 
user dbus session if one's not already running, then runs the supplied 
command, in this case startplasma-wayland , which (provided it can find 
the dbus session it needs) does the rest of the work of starting a plasma 
session from the commandline.

Since all my usual shell-exported environment is inherited, it's all there 
for the plasma session, including my customized XDG_* exports.

I do use symlinks (alike RJVB) but (in XDG_* context at least) they're to 
catch anything that tried to hard-code a default path (or portion thereof, 
say ~/.config instead of the ~/config without a dot I've actually set) 
instead of using the XDG_* variable pointer they're supposed to use.

Tho I /did/ have a bug at one point, due to kwin_wayland setting filecaps 
to allow it to switch to real-time scheduling (something relatively new 
for it at the time).  For security reasons such filecaps drop much of the 
inherited environment and kwin along with much of my plasma session was 
missing my TMPDIR setting -- the devs had taken pains to re-set various 
other vars including the XDG_* vars, but they'd missed TMPDIR.  The 
easiest workaround for me at the time was setting my (Gentoo) package.use 
for kwin to -filecaps so the kwin package was built without that support 
(the realtime scheduling was new at that time after all, and if kwin had 
done without it for decades, it could very well do without it a few months 
longer), and it quit deleting inherited vars it needed to keep, but 
eventually the kde devs fixed the bug, and TMPDIR was reinherited properly 
along with the rest of the environment the startup needed to keep, so I 
could delete that package.use workaround, and I've not had a problem with 
missing environment since.


As for that second possible solution I mentioned... RJVB likely doesn't 
know about this as he deliberately uses a very old version of most of KDE 
(IIRC kde4.something)... which is his right and more power to him (/I/ 
definitely respect him for the choice; it's for sure not the easy or non-
technical one and he really does know his thing, better than I do mine in 
many cases!), but it does mean his troubleshooting and help attempts are 
limited for newer features...

So here's the deal.  For new enough plasma, when started by means of the 
usual graphical login, when operating on the now usual systemd-based Linux 
system, plasma's startup sequence is now managed and controlled by 
systemd-logind and the normal user's systemd session (as opposed to the 
system session).

That has changed a lot of things from the old way a kde session was 
managed, taking advantage of systemd's reliable service tracking and when 
necessary restart capacities to make the various plasma components much 
more reliable, order the startup appropriately, keep services running when 
they should be, order the shutdown appropriately and reliably stop 
services (along with everything they've forked or otherwise launched in 
the mean time) when they should be, etc.  And for typical systemd-based 
Linux systems the integration is planned to further increase over time, 
tho kde/plasma is *NOT* cutting off its freebsd folks or those like me who 
prefer a non-GUI login and starting plasma from a logged-in CLI session -- 
we just won't get "the full experience" of the systemd-integrated plasma 
session management, is all, and facts being facts, may have more bugs to 
report for fixing as the automated CI testing more and more assumes the 
systemd-managed session (for Linux anyway).

Since as I said I do CLI login I'm missing "the full integration 
experience" and don't know all the details, but here's the idea.  If your 
plasma sessions are using a new enough plasma and frameworks, you should 
be able to use normal systemd services and units and environment-control 
mechanisms, and be able to use systemd user instance to set and export the 
vars you want in the session, before any other bits of the session that 
need to inherit those settings can run.

I know nothing about the nfs side, and because I use a CLI login I don't 
know too much about the *DM GUI login, but from what I know of systemd and 
how the user session starts from logind and pam before other bits of the 
user session, if you need something inherited by the rest of the user 
session, that's the logical place to go researching a config method that 
can make it happen.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman