Summary: | x11-misc/sddm-0.20.0-r1 and sys-apps/systemd-utils-254.5-r1[tmpfiles] - xauth file removed after 10 days | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | aporilel |
Component: | Current packages | Assignee: | LxQt maintainers <lxqt> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aporilel, flow, kde, M4rkusXXL, systemd |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://github.com/sddm/sddm/pull/1805 https://bugs.gentoo.org/show_bug.cgi?id=910233 https://bugs.gentoo.org/show_bug.cgi?id=917777 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
aporilel
2023-11-01 13:50:38 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. 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(-) |