Package: xdm
Version: 1:1.1.11-6.1
Severity: minor
In trixie with sysvinit-core as init, pid 1's environment contains HOME=/.
When xdm starts from /etc/init.d/xdm, it inherits HOME=/ and passes it
over to Xorg.
At some point, the X server loads one of the mesa modules
(nouveau_drv_video.so r600_drv_video.so radeonsi_drv_video.so
virtio_gpu_drv_video.so libvdpau_d3d12.so libvdpau_nouveau.so
libvdpau_r600.so libvdpau_radeonsi.so libvdpau_virtio_gpu.so
libvulkan_intel.so libvulkan_intel_hasvk.so libvulkan_lvp.so
libvulkan_nouveau.so libvulkan_radeon.so libvulkan_virtio.so
libgallium-25.0.7-2.so) and begins to write shader data to the
filesystem cache.
The location of the cache is configured by the XDG_CACHE_HOME variable,
which is not set in xdm/Xorg's environment, but the freedesktop spec
provides a helpful fallback: $HOME/.cache. Therefore the cache lands
in /.cache, but nobody notices, because of the initial dot.
I was not able to find the point in SysVinit's sources where HOME is
set to "/", and I guess it happens before /sbin/init is executed, but
have no time to investigate.
Perhaps during the upgrade from bookworm to trixie I missed a package
recommended-but-not-required that would have solved the problem in a
brilliant way.
Anyway, I relocated the misplaced cache to /run/xdg-cache with the
addition of the line
XDG_CACHE_HOME=/run/xdg-cache; export XDG_CACHE_HOME
to /etc/init.d/xdm, similar to the workaround for ALSACTLHOME in
/etc/init.d/alsa-utils.
That's why I'm filing this report against xdm, although I'm well aware
that xdm is not the culprit.
Best regards,
g.
-- System Information:
Debian Release: 13.3
