[Bug 1870585] Re: Not cleaning /var/tmp by default

[Dan Streetman]

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


** Bug watch added: Debian Bug tracker #773313
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773313

** Bug watch added: Debian Bug tracker #675422
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675422

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1870585

Title:
  Not cleaning /var/tmp by default

Status in systemd package in Ubuntu:
  New

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?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1870585/+subscriptions