Re: how to increase space for tmpfs /tmp
- To: firstname.lastname@example.org
- Subject: Re: how to increase space for tmpfs /tmp
- From: Roger Leigh <email@example.com>
- Date: Mon, 2 Apr 2012 14:30:34 +0100
- Message-id: <[🔎] 20120402133034.GK30121@codelibre.net>
- In-reply-to: <20120330201203.GB3637@big.lan.gnu>
- References: <20120328125050.GZ4122@sid.nuvreauspam> <firstname.lastname@example.org> <20120328162654.GO4122@sid.nuvreauspam> <email@example.com> <20120328185501.GS4122@sid.nuvreauspam> <firstname.lastname@example.org> <20120328221019.GV4122@sid.nuvreauspam> <20120328225803.GB6463@big.lan.gnu> <CAOdo=SyhbUEwdT8cS4JXUgj30KCyzHoZP5M6yWOVO-NH_=wc-A@mail.gmail.com> <20120330201203.GB3637@big.lan.gnu>
On Fri, Mar 30, 2012 at 02:12:03PM -0600, Paul E Condon wrote:
> It is my understanding that the directory that one wishes to use in
> TMPDIR must be mentioned in a line in /etc/fstab for this to work, and
> a block special mountable device must be mentioned in that line.
This understanding is incorrect. TMPDIR is just an environment
variable which may be set to any directory of your choice, which
will then be used as the default place to put temporary files.
It does not care about fstab or any other settings.
> this is the way it does work on my system. Choise of TMPDIR did not
> have this restriction in the past. This change has implications for
> many packages.
I sincerely doubt it does work this way on your system. There has
not, and will not be, any change to TMPDIR. Not least of which it
being an application-level feature typically used by functions
opening/creating temporary files, none of which have been changed.
What is or is not mounted on /tmp will not make one jot of
> My point is that competent developers should check this
I will be happy to investigate upon better understanding of what
"this" actually is. It will need some concrete information though,
including exact details of how to reproduce any problems, and it
should also show it's something that was working in stable, otherwise
it's not a related issue. I'll need to know what you did, what you
observed and what you expected; currently you haven't provided any
Just for the record, when these changes were introduced (nearly a
year ago, BTW), I extensively tested with *all* combinations of
RAMTMP and fstab entries. I made sure they all worked, including
every feature such as overriding the defaults. In all this time, no
one has complained that the logic was broken. (That the defaults
were suboptimal, sure, but not that it did not work.)
There is *no* magic going on here. Read the init scripts to confirm
this for yourself.
- if RAMTMP=yes, a tmpfs is mounted on /tmp. The defaults are taken
from /etc/default/tmpfs (or /etc/fstab in preference if an entry
for tmpfs on /tmp exists).
- if RAMTMP=no, we do nothing. Nothing *at all*.
- if there's an entry for /tmp in /etc/fstab, it's mounted just like
a regular filesystem. So if RAMTMP was no, and no entry exists in
fstab, nothing will be mounted.
So, as I already mentioned to you in private email last week, which
you appear to have either not read or misunderstood, according to the
continuing discussion here, all you need to do is:
1) Set RAMTMP=no
2) Remove any entries for /tmp from /etc/fstab
and /tmp will just be the same directory on the root filesystem you
Other than defaulting to mounting a tmpfs on /tmp, there have been
*no other changes*!! I tend to suspect from this thread that the
problems you are experiencing are entirely self-inflicted, because
they make no logical sense--there's no requirement for a /tmp
entry, and no suggestion of one, and the TMPDIR stuff does not
square with reality.
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800