[conspire] tmpreaper and use of /tmp as scratch space (was: Install openscad)

[Rick Moen]

I wrote:

> Sure.  I tend to use /tmp/ .

I figured I should revisit this matter and explain _why_, plus a bit
about how.

/tmp is, as the name would suggest, by tradition a temporary cubbyhole
to put things.  Depending on the details of how your system is
constructed and configured, it will be in one way or another
self-emptying.  Which seems like A Good Thing for many use-cases, as
long as you're clear about under what circumstances / when files left in
/tmp will evaporate.  (I really don't want to go waaay out in the weeds
and discusse similar places like /var/tmp.  Some other time.)

The beauty of the name '/tmp' is that it automatically conveys the need for
caution about using it for long-term storage, e.g., 'Don't leave sitting
here stuff you'd miss if it got erased.'  And it's great for temporary 
storage.  By contrast, Unix newcomers tend to default to just using
their homedirs (and/or subdirectories thereof) as scratch space -- and
then realise a year or so later that the home tree has become hideously
overgrown with junk.  My main point (point #1 of 2) is to encourage
(properly informed) use of /tmp, instead.  _Because_ it's self-cleaning.


So, we must now get to the 'properly informed' bit.

Your /tmp is probably mounted from persistent mass storage (hard drive
or SSD).  Or (much less commonly), you / your helper / distro defaults might
have decided to mount tmp from RAMdisk, as type tmpfs or ramfs.[1]
Look in /etc/fstab, to see.

Filesystems mounted from RAMdisk are by design volatile (in contrast
to persistent).  Contents go 'poof' upon any system restart / reboot / crash.

So, using /tmp space for working files on a RAMdisk means the erase
behaviour can be more sudden, less deterministic, than with /tmp on
persistent storage.  In that case (RAMdisk), /tmp will get cleared out
by all intentional restarts, as well as any unintentional ones.  _And_
cleared out by system tmpreaper and reboot scripts, which apply to all
implementations of /tmp, and which we'll cover next.

Absent volatile-storage issues, files left in /tmp/ will 
stick around indefinitely _unless_ there's a boot script to clean out 
old files at startup, and/or a system maintenance script or other type
of utility running to periodically remove old, not-recently-touched
files from it.  Those latter tools are often, by tradition, called
'tmpreaper'.  I'll use Debian as an example.[2] 

On Debian, there's a daily cron job, /etc/cron.daily/tmpreaper . I'll
not quote it here, but see it (or its equivalent for your distro) for
details.  Its configuration file (also worth a skim-read) is typically
/etc/tmpreaper.conf .  In Debian's case (point #2 of 2), the default
number of days files are to be kept if unmodified is in a different file
(cross-referenced within /etc/tmpreaper.conf), /etc/default/rcS --
which, IMO, you should configure to suit   Here's the relevant lines
from my /etc/default/rcS :

## Time files in /tmp are kept in days.
TMPTIME=30

The /etc/default/rcS value gets consulted and its retention time applied
to /tmp contents at startup on Debian systems even if there's no nightly
tmpreaper run.  The advantage of using that file's TMPTIME value is that
tmpreaper will do likewise, so you can set retention identically for
both cleaning mechanisms in one place.

Fine details can be tuned via /etc/tmpreaper.conf, but the basic
behaviour is as shown above:  If I leave files sitting around in /tmp
unchanged for longer than a month, the nightly tmpreaper run (or the
boot scripts, if I reboot) will delete those old, unused files.
Personally, I think 30 days is about right.  Many systems default to 7,
which IMO is a bit short.

Obviously, Linux distributions differ in where they handle this, but
it's probably not difficult to find, and I'd encourage doing so.


In a different thread, replying to Elise, I wrote:

> The 'env' utility is an indirect reference tool.  See:
> https://en.wikipedia.org/wiki/Env  Note that cautions in the final
> paragraph of that Wikipedia page, as the 'env' utility is something of a
> two-edged sword.

In case it wasn't obvious, that was supposed to be '_the_ cautions'.

[1] https://www.jamescoyle.net/knowledge/951-the-difference-between-a-tmpfs-and-ramfs-ram-disk

[2] More at https://www.thegeekstuff.com/2013/10/tmpreaper-examples/