HA. There it is https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13614
Turns out mesa wasn't even looking at $HOME until recently. In 20223 (when slackware 15) came out, the behavior was /* Determine path for cache based on the first defined name as follows: * * $MESA_GLSL_CACHE_DIR * $XDG_CACHE_HOME/mesa_shader_cache * <pwd.pw_dir>/.cache/mesa_shader_cache */ Since the uid of the "calling process" is root, it probably figured out that the home folder was /root and used that. But now that it's looking at $HOME it grabs / since that is what is set before a user logs in. All this just to keep the top of my filesystem clean and tidy. -Ben On Tuesday, April 22nd, 2025 at 5:30 PM, Ben Koenig <[email protected]> wrote: > Yeah, this was the same in the older sddm-19 used in slackware 15. I checked > and I don't see any significant changes in how Slackware sets up the > environment before launching sddm so my best guess is that something changed > in how mesa parses that variable. > > It also looks like this is specific to how sddm runs on X. When using wayland > it goes through a whole different process. > > Maybe mesa treated / as an invalid value or something who knows. Regardless > I'm of the opinion that sddm should respect the system environment in which > it runs. That's kind of the whole point of an environment variable. > > I expect my processes to listen when I tell them what $HOME is... > > -Ben > > > > > On Tuesday, April 22nd, 2025 at 5:18 PM, Russell Senior > [email protected] wrote: > > > git blame says: > > > > d42700a3 (Stefan Majewsky 2015-08-22 14:05:17 +0200 270) > > env.insert(QStringLiteral("HOME"), QStringLiteral("/")); > > > > So, those lines have been there since A WHILE. > > > > -- > > Russell > > > > On Tue, Apr 22, 2025 at 4:51 PM Ben Koenig [email protected] wrote: > > > > > Figured it out. SDDM has some code where they manually set the > > > environment for their subprocesses which stomps on the system variables. > > > > > > So you are technically correct Russell, sddm forks off to a bunch of > > > different subprocess. I checked the source code and sddm manually creates > > > an environment for these processes to run in and sets that. > > > > > > <code> > > > // create cursor setup process > > > QProcess *setCursor = new QProcess(); > > > // create display setup script process > > > QProcess *displayScript = new QProcess(); > > > > > > // set process environment > > > QProcessEnvironment env; > > > env.insert(QStringLiteral("DISPLAY"), m_display); > > > env.insert(QStringLiteral("HOME"), QStringLiteral("/")); > > > env.insert(QStringLiteral("PATH"), mainConfig.Users.DefaultPath.get()); > > > env.insert(QStringLiteral("XAUTHORITY"), m_authPath); > > > env.insert(QStringLiteral("SHELL"), QStringLiteral("/bin/sh")); > > > env.insert(QStringLiteral("XCURSOR_THEME"), > > > mainConfig.Theme.CursorTheme.get()); > > > setCursor->setProcessEnvironment(env); > > > displayScript->setProcessEnvironment(env); > > > </code> > > > > > > I patched it so HOME is set for "/root" and recompiled and BEHOLD - it > > > stopped generating /.cache. Looks like upstream is not adhering to the > > > system environment. > > > > > > -Ben > > > > > > On Tuesday, April 22nd, 2025 at 3:29 PM, Russell Senior > > > [email protected] wrote: > > > > > > > The environment something runs in can sometimes be confusing. For > > > > example, if the program forks, the exec operation that starts the > > > > child can clear the environment. If you can start the program with an > > > > strace wrapper, following forks and logging to a file, that might > > > > shine some light on the problem. Something like: > > > > > > > > strace -f -ttt -s256 -o/tmp/strace-sddm.log <sddm-command-line> > > > > > > > > where > > > > > > > > <sddm-command-line> is the normal startup command. > > > > > > > > You'll have to figure out where that command is invoked. > > > > > > > > -- > > > > Russell > > > > > > > > On Tue, Apr 22, 2025 at 3:21 PM Ben Koenig [email protected] > > > > wrote: > > > > > > > > > I'm sure that's what it is, but then that raises the question of > > > > > WHICH variable. These are not undocumented features, and I've > > > > > literally set all the relevant variables but it decides it doesn't > > > > > care... > > > > > > > > > > sddm-greeter works as expected. It puts everything in /var/lib/sddm > > > > > like a good little program. > > > > > > > > > > -Ben > > > > > > > > > > On Tuesday, April 22nd, 2025 at 3:13 PM, Russell Senior > > > > > [email protected] wrote: > > > > > > > > > > > I didn't parse all the C code, but it could be something has an > > > > > > empty > > > > > > variable ("") and that's getting appended with /.cache/<etc> > > > > > > > > > > > > -- > > > > > > Russell > > > > > > > > > > > > On Tue, Apr 22, 2025 at 3:10 PM Ben Koenig > > > > > > [email protected] wrote: > > > > > > > > > > > > > I'll take a look at the QML_DISABLE_DISK_CACHE variable. > > > > > > > > > > > > > > I just did some testing and it looks like some part of SDDM or > > > > > > > mesa is not obeying both the HOME and XDG_CACHE_HOME variables > > > > > > > when sddm is launched. I confirmed that the vars are set in the > > > > > > > environment when sddm.bin launches but it still creates 1.9MB of > > > > > > > data in /.cache. > > > > > > > > > > > > > > -Ben > > > > > > > > > > > > > > On Tuesday, April 22nd, 2025 at 3:00 PM, Robert Detjens > > > > > > > [email protected] wrote: > > > > > > > > > > > > > > > No disk cache in root on Fedora 42 / SDDM 0.21.0, though there > > > > > > > > are some > > > > > > > > under `/var/lib/sddm/`. > > > > > > > > The systemd unit environment disables some other different disk > > > > > > > > caching for > > > > > > > > QT stuff, but the bug refs look unrelated to the shader cache: > > > > > > > > > > > > > > > > `# workaround https://bugzilla.redhat.com/1686675 # see also > > > > > > > > https://bugreports.qt.io/browse/QTBUG-58508 > > > > > > > > QML_DISABLE_DISK_CACHE=1` > > > > > > > > > > > > > > > > On Tue, Apr 22, 2025 at 1:45 PM Ben Koenig > > > > > > > > [email protected] > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Hey all, got a really random Linux question. > > > > > > > > > > > > > > > > > > Does anyone here who uses SDDM to log into their computer > > > > > > > > > have a bunch of > > > > > > > > > mesa cache files in /.cache ? > > > > > > > > > > > > > > > > > > Yes, that's a hidden .cache folder in /, you'll need to use > > > > > > > > > 'ls -a /' to > > > > > > > > > find it. I'm specifically interested in systems running sddm > > > > > > > > > versions >=20 > > > > > > > > > but if you are on an older distro using 19 and have it that > > > > > > > > > would be > > > > > > > > > interesting as well... > > > > > > > > > > > > > > > > > > There's something funky going on in slackware -current and > > > > > > > > > I'm too lazy to > > > > > > > > > launch a new VM when I can ask users on other distros. That > > > > > > > > > and the PLUG > > > > > > > > > list has been a bit slow lately :) > > > > > > > > > > > > > > > > > > -Ben
