Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 916623 - x11-misc/sddm-0.20.0-r1 and sys-apps/systemd-utils-254.5-r1[tmpfiles] - xauth file removed after 10 days
Summary: x11-misc/sddm-0.20.0-r1 and sys-apps/systemd-utils-254.5-r1[tmpfiles] - xauth...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: LxQt maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-11-01 13:50 UTC by aporilel
Modified: 2023-12-03 18:44 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description aporilel 2023-11-01 13:50:38 UTC
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
Comment 1 aporilel 2023-11-01 13:59:51 UTC
see: https://github.com/sddm/sddm/pull/1805
Comment 2 Mike Gilbert gentoo-dev 2023-11-06 17:00:28 UTC
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.
Comment 3 Mike Gilbert gentoo-dev 2023-11-06 19:56:21 UTC
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.
Comment 4 Mike Gilbert gentoo-dev 2023-11-06 20:00:20 UTC
I guess a common case might be a portable system that is suspended for a couple of weeks.
Comment 5 aporilel 2023-12-03 18:44:46 UTC
>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.