/var/lib/lightdm/ contains xdg files

[stargazer]

I have a couple of questions. Everything has been working and I’m content to leave things as they are. But maybe I could tweak things for the better

1. /var/lib/lighdm contains the xdg user dirs. The files are created on log in. It isn’t hurting anything, but can it be prevented? The .Xauthority file is empty. The real one is in /var/run/lightdm/.

===> ls -1a /var/lib/lightdm
.Xauthority
.cache
.config
.local
Desktop
Documents
Downloads
Music
Pictures
Public
Source
Templates
Video

2. It seems lightdm fails on log in and is restarted. It isn’t noticeable from a user’s perspective, but it does appear to be consistent. I went back to journalctl -b -90 and same thing was happening.

lightdm[686]: pam_unix(lightdm-greeter:session): session closed for user lightdm
systemd[1]: session-c1.scope: Deactivated successfully.
systemd-logind[568]: Session c1 logged out. Waiting for processes to exit.
systemd-logind[568]: Removed session c1.
systemd[1]: lightdm.service: Main process exited, code=exited, status=1/FAILURE  
systemd[1]: lightdm.service: Failed with result 'exit-code'.
systemd[1]: lightdm.service: Scheduled restart job, restart counter is at 1. <---
systemd[1]: Stopped Light Display Manager. <---
systemd[1]: Starting Light Display Manager... <---
systemd[1]: Started Light Display Manager.

[anon89812132]

/var/lib/lightdm is the home directory of the lightdm user which is the user account used to run greeters; by default is and should not be readable by any other user account, that means you actually run the ls -1a as root or with sudo, or you changed default permissions yourself. System will now boot with that directory completely empty.

The systemd thing might be related to something else.

[stargazer]

@anon89812132

you actually run the ls -1a as root or with sudo

Um, yes. I am the administrator. Just wanted to provide an example of what I meant by xdg dirs and files in this location. I haven’t seen the xdg user dirs in /var/lib/lightdm on other distros.

Perhaps the restart of lightdm is residual from the original problem way back:

How to set the hostname assigned by DHCP server? fallback-hostname breaks transient hostname

New install of latest stable XFCE ISO, 21.0.7. The machine was running the previous version with no issues. The external symptom is, I enter my password and lightdm just redisplays the greeter. I enter my password a second time and I get successfully logged on. However, looking at the journal, I see lightdm-gtk with a segfault in libcairo and a corresponding coredump, /usr/bin/lightdm-gtk-greeter. It is similar to: https://bugs.archlinux.org/task/47694 And the arch wiki work-around is to …

I haven’t seen an official solution. My work around was to wait until hostnamectl --transient was valid, in the greeter-setup-script. One user felt they had success by adding network-online.target to the lighdm service. Like I mention, everything appear to be working. Just thought I’d take a moment and revisit.

[stargazer]

To prevent the coredump, my work around is to put a wait on greeter-setup-script in lightdm.conf until hostnamectl --transient is valid.
How to set the hostname assigned by DHCP server? fallback-hostname breaks transient hostname - #6 by stargazer

The above solution has been improved and it solves 2 issues:

1. gtk-greeter fails
2. lightdm restarts even with the greeter-setup-script, but it prevented the segfault

The new solution is to create a systemd service that lightdm requires. The service will wait until the transient hostname is set by dhcp.