On Mon, 6 May 2024 at 09:40, Michael Biebl <bi...@debian.org> wrote: > > 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 30d > > Files 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.
Defaults are defaults, they are trivially and fully overridable where needed if needed. Especially container and VM managers these days can super trivially override them via SMBIOS Type11 strings or Credentials, ephemerally and without changing the guest image at all.
