Bug 826015 (F18TmpOnTmpfs) - TRACKER tmp-on-tmpfs
Summary: TRACKER tmp-on-tmpfs
Alias: F18TmpOnTmpfs
Product: Fedora
Classification: Fedora
Component: distribution
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Radek Vokál
QA Contact: Radek Vokál
URL: https://fedoraproject.org/wiki/Featur...
Depends On: 827581 858264 858265 858266 892063 895109 895444 981712 981733 990197 990208 990988 991228 991524 1222061
TreeView+ depends on / blocked
Reported: 2012-05-29 11:14 UTC by Lennart Poettering
Modified: 2015-05-15 16:07 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-02-17 14:16:07 UTC
Type: Bug

Attachments (Terms of Use)

Description Lennart Poettering 2012-05-29 11:14:19 UTC
A tracker bug to keep track of problems resulting by the tmp-on-tmpfs feature:


Comment 1 joshua 2012-09-13 04:17:48 UTC
My users move too many files to /tmp ... is there a default limit on how much memory tmpfs will consume?

The kernel and system dying as it runs out of memory when any spiteful user on the system does this:

cat /dev/zero > /tmp/toobig

... would be ridiculous.

Comment 2 Lennart Poettering 2012-09-13 19:03:51 UTC
The default disk size is at 50% of the physical amount of RAM.

Comment 3 joshua 2012-09-19 15:04:38 UTC
I'd like to make an argument against this being the default setting in general.

Many people who understand that tmpwatch cleans things every 7 days on the old system, and even those who don't, have the files they moved or copied to /tmp exist for a set number of days.  

Changing to tmpfs using memory means that this could be much shorter, given the often random state of power.  "Don't worry, I copied it to /tmp" isn't any good if we rebooted or lost power.

Also, by using volatile memory, we are introducing another element of instability to what before was very predictable.  If you argue that it is needed so that "/tmp is clean on every boot"... why not simply add something to boot that does "rm -rf /tmp/*" ?

The reverse is also true.  Lets say we *don't* have a power outage for months... possibly large files that are just under 50% of memory... do they get cleaned out every week, or do they last until the next power cycle?  Even if they do get removed every 7 days, memory is very often scarce.  The argument isn't that /tmp shouldn't be used... it *is being used*.  For whatever reason, a file now exists in /tmp ...  is it so important as to burn memory simply so it need not exist on disk?   Many many many systems are long on disk space, and short on memory.  Cheap laptops.  Older servers.  Newer cheap servers.

Bring Fedora closer to the memory burning and less predictable way that other Unix and Linux distributions do it isn't a worthy goal in and of itself if the default outcome leaves users and system admins worse off.

Comment 4 Richard W.M. Jones 2012-09-19 15:15:48 UTC
These arguments have been well-covered already
on the FESCO ticket to have this misfeature reverted.
See: https://fedorahosted.org/fesco/ticket/940

Comment 5 Joseph D. Wagner 2012-10-25 06:50:31 UTC
Has Brasero been updated to use /var/tmp instead of /tmp?  (I'm not a F18 tester, so I don't know.)  Last time I used it to burn a DVD, it used /tmp to store the 4.7 GB image before burning it.

Comment 6 Daniel Yek 2012-12-19 16:40:19 UTC
Just a note that cscope is one such application that needs to be fixed to write to /var/tmp, instead of /tmp.

I have to use this workaround in Fedora 18 Beta to enable cscope to complete its indexing:
  TMPDIR=/var/tmp cscope -b -q -k

I'll try to file a bug report against cscope once I resolve my SourceForge account problem, but feel free to file the bug report if I haven't done so.

Comment 7 joshua 2012-12-19 17:14:00 UTC
If this misfeature has been reverted, why is there an effort to change applications to stop using /tmp?

Comment 8 Bill Nottingham 2012-12-19 17:22:48 UTC
Even if /tmp is a real filesystem, it's probably not wise to assume it can handle arbitrarily large sizes. Furthermore, apps that assume /tmp is persistent across boots, or even across program invocations still need fixed.

That being said, I'm not sure cscope falls into those categories.

Comment 9 Daniel Yek 2012-12-20 19:00:13 UTC
As promised, I opened a ticket against cscope to consider using /var/tmp here:

Comment 10 Henrique Martins 2013-01-29 20:00:03 UTC
Opened a ticket against mysql (mysql-libs) as at least mysqldmp and mysql_upgrade fail on my system due to a small /tmp

Comment 11 Fedora End Of Life 2013-04-03 16:31:33 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:

Comment 12 mhtempweb 2013-06-07 07:44:13 UTC
I am just an ordinary user.  But I am so enraged by this that I have gone to the trouble to sign up to register my dissatisfaction (to put it mildly).

The wiki states:

'The user experience should barely change. This is mostly a low-level change that has little visibility to the user.'

WRONG - It is causing regular failures.  The release notes recommend a minimum of 1Gb RAM. Which is a commitment from Fedora that systems with 1Gb RAm can run F18. So under this setup only 500Mb of /tmp space is available for every process and all users.  You only have to state that to realise this is a disaster waiting to happen.

So for example fedora-arm-installer needs 1.78Gb of /tmp space otherwise it just hangs indefinitely.

Comment 13 Lennart Poettering 2013-06-10 13:23:49 UTC
mhtempweb, please file a bug against fedora-arm-installer and ask them to use /var/tmp for such large unbounded files. Thanks.

Comment 14 Steevithak 2013-07-09 20:18:59 UTC
I'm unable to restore my Evolution email backup from Fedora 18 apparently because of this bug. Evolution just hangs part way through the restore and from what we can tell, it's running out of space on /tmp. So with the new size limit on /tmp it looks like Evolution is limited to restores that are less than 2GB uncompressed. (my Evolution backup is more like 10GB compressed).

Also Midnight Commander's ability to browse archive files (gz,bz2,zip,etc) is broken for the same reason, it's constantly running out of space on /tmp. 

And what about tar/gzip in general - don't they rely on /tmp?

Given how large hard disks are these days, it seems crazy to suddenly slap a 2GB size limit on the /tmp directory. I work with files much larger than this on a daily basis and now every program that does so apparently has be changed and updated to avoid use of the /tmp directory? I suspect developers will just route around the damage by adopting random other tmp directories (e.g. /var/tmp, /local/tmp, /usr/tmp, /wherever/tmp). Except now it'll be hard to find where any given program is parking its tmp files because they'll be scattered all over the place. :(

Comment 15 joshua 2013-07-09 22:45:56 UTC
/tmp is too small when using memory, and memory is too precious on a great many machines to use it as a filesystem.  The solution isn't to increase the amount of memory allocated in the first scenario, or to decrease the amount in the second... it is to stop using memory as disk altogether.

Using memory as /tmp has not been shown to increase system performance in any tangible way.  Other side benefits like /tmp's contents being erased during reboot are trivially easily to reproduce with changes to startup scripts.

For the extreme few corner cases requiring unquenchable filesystem IO, ramdisk could be used on non-system custom locations, however /tmp is not one of those corner cases.

Comment 16 Lennart Poettering 2013-07-11 22:03:08 UTC
Please file a bug against the relevant applications to place potentially large data in /var/tmp rather than 7tmp.

Comment 17 Steevithak 2013-08-01 15:25:05 UTC
Has there been any progress on this bug yet? I'm still unable to recover my email from F17 because Evolution on F18 can't restore the backup archive due to "out of disk space" errors, apparently caused the new limit on /tmp space. Even a work-around  that would let me turn off the 2GB limit on /tmp for just long enough to recover my email would be helpful...

Comment 18 Steevithak 2013-08-01 15:31:15 UTC
sorry, I meant F18 -> F19 there...

(In reply to Steve Rainwater from comment #17)
> Has there been any progress on this bug yet? I'm still unable to recover my
> email from F17 because Evolution on F18 can't restore the backup archive due
> to "out of disk space" errors, apparently caused the new limit on /tmp
> space. Even a work-around  that would let me turn off the 2GB limit on /tmp
> for just long enough to recover my email would be helpful...

Comment 19 Henrique Martins 2013-08-01 15:33:34 UTC
systemctl mask tmp.mount

Comment 20 Karel Volný 2013-08-01 15:42:19 UTC
(In reply to Steve Rainwater from comment #17)
> Has there been any progress on this bug yet? I'm still unable to recover my
> email from F17 because Evolution on F18 can't restore the backup archive due
> to "out of disk space" errors, apparently caused the new limit on /tmp
> space.

see comment #16, please file a bugreport for Evolution about this (to use /var/tmp instead) and make it blocking this bug

> Even a work-around  that would let me turn off the 2GB limit on /tmp
> for just long enough to recover my email would be helpful...

(In reply to Henrique Martins from comment #19)
> systemctl mask tmp.mount
> reboot

or make sure that you have enough RAM+swap and remount /tmp with bigger size like:

# mount -o remount,size=50g /tmp

you can also use percentage of RAM instead of fixed units; see man mount

Comment 21 Steevithak 2013-08-01 15:58:59 UTC
Thanks, there's no way I could put enough RAM in the computer to make a RAM based /tmp big enough to hold my mail archive. The computer tops out at 16GB (it's a laptop)  I'll google the "systemctl mask tmp.mount" and see what that does. Will that switch /tmp back to working like it used to where the tmp size was only limited by disk space instead of the 2GB limit?

Regarding the Evolution bug, I thought I'd already filed one and had it rejected because they considered having such a tiny /tmp directory not to be an Evolution bug, but a configuration bug on the distro. But I'll double-check and see if I can track down the bug report or file a new one.

Comment 22 Steevithak 2013-08-02 16:08:16 UTC
Here's another bug related to tmpfs - Midnight Commander's archive browsing feature is broken by the new size limit on /tmp: bug 981733

Comment 23 Steevithak 2013-08-02 16:21:13 UTC
I couldn't find the previous bug I'd filed against Evolution for the /tmp problem. Either I imagined it or I filed it on another bugzilla (maybe the Gnome bugzilla?). Anyway, I filed a new one: bug 991524

Comment 24 Steevithak 2013-08-05 15:44:53 UTC
It sounds like what the Evolution developers are saying is that Evolution relies on gzip to decompress archives, so the new size limit on /tmp isn't their problem, it's a problem with gzip. So, should someone file a bug against gzip using /tmp or has that already been done?

Comment 25 Steevithak 2013-08-17 20:33:30 UTC
(In reply to Henrique Martins from comment #19)
> systemctl mask tmp.mount
> reboot

Tried this but it didn't help. Evolution still dies during the restore process and still provides no meaningful error message. Very frustrating... Can anyone point to me a completely manual procedure for restoring an Evolution backup?

Comment 28 Fedora End Of Life 2015-01-09 17:10:08 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 29 Fedora End Of Life 2015-02-17 14:16:07 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.