/var/lib/lightdm/ contains xdg files

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 :slight_smile:

  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
  1. 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.

/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.

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:

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.

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.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.