Not cleaning /var/tmp by default

Bug #1870585 reported by Bryan Quigley
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
systemd (Debian)
Fix Released
Unknown
systemd (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

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?

Eric Desrochers (slashd)
tags: added: sosreport sts
Revision history for this message
Dan Streetman (ddstreet) wrote :

> 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?

Revision history for this message
Dan Streetman (ddstreet) wrote :

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

Dan Streetman (ddstreet)
tags: added: ddstreet
Revision history for this message
Bryan Quigley (bryanquigley) wrote :

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

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

Changed in systemd (Debian):
status: Unknown → New
Nick Rosbrook (enr0n)
Changed in systemd (Ubuntu):
importance: Undecided → Wishlist
Revision history for this message
Nick Rosbrook (enr0n) wrote :

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.

Changed in systemd (Ubuntu):
status: New → Fix Released
Changed in systemd (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.