Feature changed by: Robert Davies (robopensuse)
Feature #309448, revision 25
Title: Clean temporary data in SUSE
Requested by: Michal Vyskocil (mvyskocil)
Partner organization: openSUSE.org
The current default behavior of SUSE is not touch files in /tmp and
others to prevent an unwanted data lost. There are at least two
requests willing to change it somehow:
* FATE#307510: Cron: set MAX_DAYS_IN_TMP different from 0
* bug#594778 - RN: include tmpwatch in a pattern
* The common meaining of /tmp is that is for temporary data. FHS says -
"Programs must not assume that any files or directories in /tmp are
preserved between invocations of the program". FHS also allows the
removal of a content of /var/tmp and /var/cache , even if those
directories should be more persistent as /tmp .
* As SUSE places the /tmp and /var on root partition by default and not
remove the content of it, the free space should be simply eaten. There
are a lot of applications in SUSE distribution that stores a lot of
data inside those dirs, but because of the common meaning - they not
removed them. For instance - Mozilla Firefox, ssh, gpg, kde, mc, Adobe
Flash, and many others. The other way is to fix all of those programs
to safely remove all content they store in /tmp after it's not needed.
* Strictly speaking the not removal of /tmp and others is not againts
* Change of the default is dangerous, especially if we are talking about
files removal, because long time SUSE users might rely on this specific
behavior of SUSE.
* The default should be SAFE and not removing of files is considered as
a safe default.
Please note this FATE is not about concrete technical solution
(existing scron script, tmwatch, tmpfs, /dev/shm, or something else).
The question is - change the default behavior to remove temporary
files, or not ? And if so, which ones and how often.
#1: Per Jessen (pjessen) (2010-05-04 11:31:51)
I'm not really sure how this differs from feature 307510, but never
mind - the only advantage of this change is to save disk space. Disk
space is becoming cheaper by the minute and Terabyte is no longer an
exotic amount reserved for large datacentres. I say we keep the safe
default in openSUSE, and leave it to the sysadmin to do the one-line
change if he or she wants to automatically purge temporary files.
#3: Michal Vyskocil (mvyskocil) (2010-05-04 12:00:54) (reply to #1)
The biggest reason is that this FATE does not recommend the technical
You're not right, the advantage is to prevent the filling of the disc
on a running system. Your argument about cheaper disc space is true
only if you consider new and new hardware. The existing one has
typically fixed amount of disc space, should not be wasted by having a
lot of unwanted data in /tmp . For instance my five year old laptop has
40GB HDD and 7GB root partition, so it is very sensitive on available
space - not all SUSE are in datacenters :-).
#5: Per Jessen (pjessen) (2010-05-05 13:25:22) (reply to #3)
So for five years you have (presumably) managed quite well without this
default setting. My argument about cheaper disk space has held true
since around 2000 when disk sizes started doubling about once a year
due to GMR. Not having temporary files purged was not an issue then, I
see no reason why it is likely to become an issue now or later (with
disk sizes continuing to grow). Neither openSUSE nor SuSE Linux have
ever done such an automatic purge by default, so I maintain it is not a
safe change as people may well have gotten used to keeping non-
temporary data in /tmp.
Given the minimal advantage, the risk of deleting non-temporary data
and that changing the retention time is a matter of five seconds with
vi, this is really not much of a feature. IMHO.
#2: Guido Berhörster (gberh) (2010-05-04 11:41:11)
Cleaning /tmp on bootup and/or periodically through a cronjob is also
common practice on all other major Linux distros (e.g. Debian, Ubuntu,
RHEL/Fedora, Mandriva) and UNIX(-like) OS (e.g. Solaris/Opensolaris,
I'd also really like to hear any use cases and reasons why users would
put any valuable data in /tmp (rather than /var/tmp or their homedir)
and expect it to persist indefinitely.
#4: Gerald Pfeifer (geraldpfeifer) (2010-05-04 13:25:25)
It's not necessarily (just) about disk size, there is also the aspect
of partitioning and /tmp may not be all that large.
It's also not primarily about data centers (which is not the key focus
of openSUSE), but more individual users or wide spread use not
necessarily governed by professional admins, and there this just
reduces risk assuming we go for a somewhat conservative default (not
just 24 hours). The use case is my significant other's machine (or
mine), not some data center.
For what it's worth, I, for one, don't want to keep all the crap that
tends to pile up under /tmp for years.
And non-expert users, of which we have many, will be surprised what
kind of staff remains under /tmp, leaving behind a trail many won't be
aware of, remaining even after months or years.
#6: Per Jessen (pjessen) (2010-05-05 13:35:35) (reply to #4)
Well, the non-expert user is exactly who I am worried about and why I
think this feature is unsafe The non-expert user won't be aware of how
the professional sysadmins would like to run things, and might just
(intentionally or not) store or have stored valuable data in /tmp.
Besides, I disagree about the use case - my use case is my datacentre
run by professional sysadmins. (who decided what the primary target
audience for openSUSE is? I thought we were still aiming to be
everything for everyone.)
#7: Guido Berhörster (gberh) (2010-05-05 13:51:08) (reply to #6)
The non-expert user will store his data in /home/non-expert where these
neatly named folders Documents, Music, Pictures etc. are. But he will
fill slowly fill up his 10G rootfs by opening lots of pdfs, mp3s,
archives etc. from Firefox (which are put into /tmp and never get
deleted) without being aware of it , let alone how to avoid this in the
#8: Per Jessen (pjessen) (2010-05-05 14:07:39) (reply to #7)
I'm less concerned about the new non-expert user, more about the OLD
ditto who had already been using e.g. /tmp for storing non-temp data.
For him this would not be a safe change, even if it was bent in neon in
the Changelog. (as for Firefox using /tmp - my FF3.6 doesn't seem to
store anything there?)
#9: Michal Vyskocil (mvyskocil) (2010-05-06 11:20:21) (reply to #8)
I'm less concerned about the new non-expert user,
more about the OLD
ditto who had already been using e.g. /tmp for storing non-temp
Are there any serious reasons why those data needs to be stored in /tmp
and should not be placed elsewhere in system? I'm sure that expert you
mention is fully able to understand the meaning of /tmp and place his
files to other safe location. Or at least disable this behavior.
As I understood your arguments - there is a bug (or rather an uncommon
behavior of SUSE, if you'd preffer it), but because some people rely on
that, so it might be not fixed/changed. And sorry, but that's not seems
to me as a right argumentation.
#11: Per Jessen (pjessen) (2010-05-06 19:41:02) (reply to #9)
No, there are no real reasons why data needs to be stored in /tmp
(unless they are genuinely temporary).
My arguments against this are:
* it is unsafe. openSUSE/SuSE Linux has not been purging /tmp at least
since 4.4.1 (my first SuSE Linux).Some innocent non-expert user might
very well end up having valuable data purged.
* the change is so easily made that it's difficult to imagine why we
are even discussing it here.
* the change brings no real world benefits.
#14: Guido Berhörster (gberh) (2010-05-07 00:15:20) (reply to #11)
* it is unsafe. openSUSE/SuSE Linux has not been
purging /tmp at least
since 4.4.1 (my first SuSE Linux).Some innocent non-expert
very well end up having valuable data purged.
That really sounds a bit far fetched. tmp is short for temporary.
tem·po·rary: lasting for a limited time
(in this case 10 days)
* the change is so easily made that it's difficult
to imagine why we
are even discussing it here.
Not to the innocent non-expert user who doesn't even know that this
option exists, that it is not turned on by default, and why he actually
wants it changed.
* the change brings no real world benefits.
has been pointed out that several times that it prevents filling up
the root patition. And not everyone has a multi-terabyte rootfs, IIRC
by default the installer creates a relatively small rootfs and assigns
the rest of the available space to a partition which gets mounted on
In effect the default setting is more likely to cause harm which is why
it should be changed and why e.g. FATE#307510 was requested in the
#15: Per Jessen (pjessen) (2010-05-07 10:46:09) (reply to #14)
Last entry on my part - in my opinion, it is not a safe change and it
brings little or no real-life benefits. The default setting has caused
little or no harm in the last 15 years, and it is difficult to imagine
why it should become more likely to cause harm in the future.
#10: Ricardo Gabriel Berlasso (rgbsuse) (2010-05-06 14:23:55)
Can, please, the people who are against this provide a clear user case
in which retaining these files is desirable? I really can't imagine
such scenario... In the 10+ years I'm using Linux I've never see anyone
using /tmp as storage folder: in fact, most people I know simply ignore
the content of /tmp and /var/tmp folders.
Some time ago a friend of mine had a problem with a print job which
went crazy: in a few seconds a log file of several GB was created
without his knowledge and afterwards he had problems to log-in in his
system because the disk was full: cleaning /var/tmp was the solution.
#12: Per Jessen (pjessen) (2010-05-06 20:25:36) (reply to #10)
Use case: Retaining files stored in /tmp in desirable when they meant
to be kept.
#13: Per Jessen (pjessen) (2010-05-06 21:00:10) (reply to #12)
Use case: Retaining files stored in /tmp is desirable when they were
meant to be kept.
#16: Ricardo Gabriel Berlasso (rgbsuse) (2010-05-07 15:38:40) (reply to
My first reaction to your "answer" was a mixture of "are you
with a "Wait, what?", but I will try to maintain the conversation in
the right track. After all, we are here exchanging ideas. Articulated
and complete ideas.
Files that enters automatically in the tmp folder have no value per se
in the long run (youtube videos, partial downloads, temporary image
files... in /var/tmp you can also find log files which only show
interesting information when something goes wrong, temporary
information from kde sessions...). Some of those files are erased by
the app that generated them, but some not, specially when the app
And as I pointed before, useless and big log files are really common,
specially when there is a crash.
Log files are useful only immediately after a crash, and if you set a
reasonably default you will not lost them.
Point is: If there is some valuable information there that needs to be
kept forever it is because the user puts it on purpose ... and I cannot
imagine why someone should put valuable information on a temporary
directory on purpose...
So, again, why we should need to keep those directories without
maintenance? Or if you prefers, why there could be on those directories
files meant to be kept? And which are those important files?
+ #18: Robert Davies (robopensuse) (2010-12-19 18:53:49) (reply to #12)
+ As per FHS, I have used files in /tmp for the Use case, that I did not
+ care about them, and wanted them automatically deleted. /tmp is
+ expected to be a local filesystem with fast access, and not expected to
+ be accessible from other hosts in network or backed up. The user Home
+ Directory or administrator project data directories, are the sane
+ locations for "retaining files".
+ As /tmp is a special case and well documented, the automatic purging of
+ temporary files, which are not wanted for retention, should as a "Use
+ Case" over turn a poorly chosen historical default in SuSE Linux.
#17: Sascha Peilicke (saschpe) (2010-05-28 16:33:05)
Another pro here is performance, when /tmp is kept in RAM via tmpfs,
access is blazingly fast (good for large compile jobs, etc.). One issue
might be a lack of sufficient physical RAM, but if /tmp needs more than
what is available swap is gonna be used anyways, so /tmp ends up on
disc again and should have the same performance as before. Nonetheless
on a netbook or a computer with only small physical RAM available, a
tmpfs solution should avoid swapping. So a /tmp size limit might be