Not cleaning /var/tmp by default

[Bryan Quigley]

1) 20.04
2) 245.2-1ubuntu2
3) I expect /var/tmp to be cleaned up in some way.
4) It's commented out per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773313

In sosreport was comparing the difference between /tmp (Ubuntu/Debian) and /var/tmp (RH) and determined that as long as /var/tmp gets cleaned on a regular basis we would prefer /var/tmp.

The bug that appears to have prompted the disabling was fixed a long time ago, can we have this 30d delete re-enabled by default?

[Dan Streetman (ddstreet)]

> 4) It's commented out per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773313

no, that's regarding a bug with the related x entries; the difference in behavior from upstream originates from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675422

To be clear:

upstream behavior:
/tmp:
 -by default, /tmp is a tmpfs (via tmp.mount service), so everything under it is lost each boot
 -however, if the tmp.mount service is disabled/removed, a 'normal' /tmp dir is created
 -with tmp.mount disabled, /tmp is *not* cleaned each boot - items are persistent
 -/tmp content is cleaned with 10d aging time
/var/tmp:
 -there is no corresponding tmp.mount for /var/tmp, so it is just a normal (temp) dir
 -it is *not* cleaned each boot - items are persistent (this is correct per FHS)
 -/var/tmp content is cleaned with 30d aging time

debian/ubuntu behavior:
/tmp
 -debian removes (actually, moves) the tmp.mount service so it is not available (by default)
 -/tmp is thus a 'normal' (temp) dir
 -debian changes the tmp.conf entry for /tmp to be 'D' instead of 'q'
 -because it is 'D', all its content is removed each boot
 -debian removes the aging time so /tmp is *not* cleaned by age!
/var/tmp
 -debian removes this tmpfiles.d entry completely, so this dir is NOT managed by tmpfiles
 -the dir is not created by systemd, but by 'base-files' pkg
 -/var/tmp content is *never cleaned up by systemd ever*
 -as a specific exception, /var/tmp/systemd-private-* content is configured separately as R!, which removes just those dirs, only at boot

There is also a minor difference in that default upstream uses 'q' which (according to the docs) only has a meaningful difference for systems with a btrfs / fs.

> In sosreport was comparing the difference between /tmp (Ubuntu/Debian) and /var/tmp (RH) and determined that as long as /var/tmp gets cleaned on a regular basis we would prefer /var/tmp.

Also note that, except Debian/Ubuntu, systems using systemd will, by default, have /tmp configured as tmpfs, so dropping really large sosreports in there may not be good.

Personally, I think there are really 3 changes to consider here, and they should be considered first for Debian and then for Ubuntu:

1. should /tmp change to a tmpfs, as upstream systemd defaults to?
2. should files under /tmp be removed with 10-day aging, as upstream systemd defaults to?
3. should files under /var/tmp be removed with 30-day aging, as upstream systemd defaults to?

Again, personally, I think #1 is a significant policy change and I don't really see a strong reason to change our default behavior.

For #2, since it's configured to be cleaned out each boot, I think a age-based cleaning policy isn't as important. A 10-day aging policy probably makes more sense when matched with upstream's default of using tmpfs.

However, for #3, as /var/tmp is persistent storage, I tend to think *some* kind of age-based cleanup does make sense. I don't know if 30 days is the right number to move to from our current never-clean, but personally I think some finite cleanup policy would be good to set by default.

Have you opened a Debian bug?

[Dan Streetman (ddstreet)]

Also, might I suggest that the sosreport package includes its own systemd tmpfiles.d config? Something like:

# Remove sosreport files on each boot
r! /var/tmp/sosreport-*

or if the policy should be age-based instead of (or in addition to) removing each boot, something like:

# Remove sosreports after 60 days
e /var/tmp/sosreport-* - - - 60d

[Bryan Quigley (bryanquigley)]

Having our own cleaning line in sosreport is certainly an option.

No, I haven't made a new debian bug on this.

[Nick Rosbrook (enr0n)]

Debian is going back to upstream behavior for this, and we will follow (except for extending the clean up age for /tmp to 30d). This will be in the next oracular upload, but we won't backport.