We have two separate issues here: a/ /tmp-on-tmpfs b/ time based clean-up of /tmp and /var/tmp
I think it makes sense to discuss/handle those separately. Regarding a/: tmp.mount as shipped by systemd uses the following mount options: "mode=1777,strictatime,nosuid,nodev,size=50%"In the past there were concerns that those 50% of available RAM wasn't a one-size-fits-all solution, especially for (LXC) containers and VMs
One also needs to keep in mind that debian-installer still offers a partitioning setup with /tmp on a separate partition. This will be created via an entry in /etc/fstab. Such a /tmp entry in /etc/fstab will override tmp.mount.
If we go with a/, then I think d-i should be updated to no longer create /tmp as a separate partition.
Regarding b/:The current setup as used in Debian is to only clean /tmp on boot (which is pointless with /tmp-on-tmpfs) and never clean up /var/tmp
The tmpfiles rule tmp.conf as shipped by systemd upstream contains: q /tmp 1777 root root 10d q /var/tmp 1777 root root 30dFiles that are older then 10 days or 30 days are automatically cleaned up. The age of the files are determined as such:
"The age of a file system entry is determined from its last modification timestamp (mtime), its last access timestamp (atime), and (except for directories) its last status change timestamp (ctime). By default, any of these three (or two) values will prevent cleanup if it is more recent than the current time minus the age field."
I'm not sure if we have software on long running servers which place files in /tmp and /var/tmp and expect files to not be deleted during runtime, even if not accessed for a long time. This is certainly an issue to be aware of and keep an eye on.
Michael
OpenPGP_signature.asc
Description: OpenPGP digital signature
