The problem occurs when the session is running for more than 10 days. sddm-0.20 creates the Xauthority file in the /tmp directory (unlike sddm-0.18 which created it in /home), but systemd-tmpfiles, which runs on a cron daily, deletes it if 10 days have passed. To reproduce: cd /tmp now=$(date +"%s"); date --set="@$((now-11*86400))"; for i in xauth*; do touch "$i"; mv "$i" _tmp; cp -a _tmp "$i"; rm _tmp; done; date --set="@$now" stat /tmp/xauth* #check all dates (access/modify/change/birth) /etc/cron.daily/systemd-tmpfiles-clean
see: https://github.com/sddm/sddm/pull/1805
It's worth noting that systemd mounts /tmp with strictatime by default, and atime is included as a criterion for the 10 day cleanup. That means your system would need to be completely idle for 10 days with no application touching the file at all. On OpenRC, /tmp probably doesn't have strictatime by default, so this would be more of an issue there. This might be a good enough reason for us to remove the /tmp cleanup from sys-apps/systemd-utils.
flow pointed out this entry in mount(8) for relatime: > relatime > Update inode access times relative to modify or change time. Access > time is only updated if the previous access time was earlier than > or equal to the current modify or change time. (Similar to noatime, > but it doesn’t break mutt(1) or other applications that need to > know if a file has been read since the last time it was modified.) > > Since Linux 2.6.30, the kernel defaults to the behavior provided by > this option (unless noatime was specified), and the strictatime > option is required to obtain traditional semantics. In addition, > since Linux 2.6.30, the file’s last access time is always updated > if it is more than 1 day old. So, even with relatime instead of strictatime, you would need to have a system where the Xauthority file is not opened at all for 10 consecutive days for this to be a problem. If /tmp is on a filesystem with the noatime option, that would be more problematic.
I guess a common case might be a portable system that is suspended for a couple of weeks.
>If /tmp is on a filesystem with the noatime option, that would be more problematic. Yes, filesystems were mounted with the noatime option and I didn't experience any problems before this incident. I was surprised that /tmp is cleaned automatically on openrc system.
Please confirm if this is fixed with 0.21.0.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dafe17091a2bfa128ee7f706d63e76cc42e4c58f commit dafe17091a2bfa128ee7f706d63e76cc42e4c58f Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2024-03-28 21:09:36 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-03-28 21:12:06 +0000 sys-apps/systemd-utils: disable auto-cleanup of /tmp and /var/tmp This can go awry when people have non-standard mount options for these paths. Closes: https://bugs.gentoo.org/910233 Bug: https://bugs.gentoo.org/916623 Closes: https://bugs.gentoo.org/917777 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-apps/systemd-utils/files/tmp.conf | 2 ++ .../{systemd-utils-254.10.ebuild => systemd-utils-254.10-r1.ebuild} | 4 ++-- .../{systemd-utils-254.8.ebuild => systemd-utils-254.8-r1.ebuild} | 4 ++-- sys-apps/systemd-utils/systemd-utils-255.4.ebuild | 4 ++-- 4 files changed, 8 insertions(+), 6 deletions(-)
