/tmp is not automatically resized until system restart

[Elias K Gardner]

this is on ubuntu intrepid development

I discovered this through an incorrect firefox dialog with more details at bug 285080. My filesystem (/) was nearly out of space. A limit of 1MB appears to have been put on the /tmp filesize. This limit caused the firefox dialog bringing my attention to the bug. I ran 'apt-get clean' which freed up over 700MB of space on /. /tmp remained limited to 1MB until the system was restarted.

/tmp should automatically be allowed to access the full amount of free space in the filesystem.

This may not be relevant but I find it interesting. All of the files in / report having the full amount of free space left on / except /sys and /proc witch report 0 bytes free and /dev which reports 1.9 GB (this is more free space than exists in the / partition) and /home which is on its own partition.

[capnjack (mccachar)]

Having the same issue, thought I'd add some detail. I'm running Ubuntu 8.04 64-bit and this issue first became apparent to me through firefox32, which I have to run for various 32-bit-only plugins.

Linux cmccabe-ubuntu 2.6.24-21-generic #1 SMP Mon Aug 25 16:57:51 UTC 2008 x86_64 GNU/Linux

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13

Filesystem Size Used Avail Use% Mounted on
/dev/sda1 53G 44G 6.9G 87% /
varrun 1.5G 140K 1.5G 1% /var/run
varlock 1.5G 0 1.5G 0% /var/lock
udev 1.5G 56K 1.5G 1% /dev
devshm 1.5G 100K 1.5G 1% /dev/shm
lrm 1.5G 44M 1.5G 3% /lib/modules/2.6.24-21-generic/volatile
overflow 1.0M 660K 364K 65% /tmp

I ran a "scrub -X" as root recently, which filled the / filesystem and I think this problem started then. I'm also wondering if this is related to my recent inability to play flash vids; google "flash video stops after 2 seconds ubuntu" for other cases. Going to *gasp* reboot.

Thanks,
Chaz

[capnjack (mccachar)]

Rebooted and now /tmp doesn't show up at all. Problem is gone. Even flash vids play now; presuming they wanted some /tmp space.

Thanks,
Chaz

[karaluh (karaluh)]

I can confirm this, Intrepid, ext3 with journaling on software raid. After upgrade df still shows 100% used space on /var after aptitude clean. I recall I had the same issues with /home and / in the past, all being on separate partitions.

[Nicholas Polydor (nickpolydor)]

Is this bug also occurring with those using the ext2 filesystem on 32 or 64-bit? What about those running Jaunty Alpha 3 (32 or 64-bit) and using ext2, ext3 or ext4?

[Elias K Gardner (zorkerz)]

I just tested this bug using an updated jaunty 64-bit virtualization using virtualbox with ext3. I don't know if or how using a virtualmachine will effect this.

I added a large file to the directory and then removed the file. /tmp immediately reported more free space reflected the files removal. So to rephrase this bug does not seem to occur in a 64bit jaunty VM using ext3.

Note: the original report was with 64-bit and ext3.

[karaluh (karaluh)]

> I added a large file to the directory and then removed the file.

Did it fill the whole partition? Was the free space left at 0%?

[Elias K Gardner (zorkerz)]

No it did not fill the whole partition there was free space left.

I started with 4 gigs free. Then added a 1.8 gig folder. This left 2.2 gigs
free. When I deleted the folder it went back to reporting 4 gigs free.

Could this possibly only happen if the leftover free space is extremely
small?

[karaluh (karaluh)]

> Could this possibly only happen if the leftover free space is extremely small?

That's exactly the point. The partition has to be 100% full.

[Elias K Gardner (zorkerz)]

ok if i get some time i will try to fill the drive completely and see if it changes anything. Although I would like to point out that when I originally filed this bug the hardrive was not 100% full it actually had at least 1MB free because thats what /tmp reported as having free.

[Elias K Gardner (zorkerz)]

I just filled the guest VM partition untill / and /tmp reported 0 bytes free space and got the same firefox error (that tells you to save somewhere else but does not let you) that lead to the original discovery of this bug. I then deleted 110MB of data and both / and /tmp reported 109.9MB free.

It appears this bug is fixed or at least no longer present. I am going to mark it as fix released. Please change it back if this is not the case.

[Elias K Gardner (zorkerz)]

no longer present in updated jaunty jackalope x64 with virtualbox as of 25 jan 2009.

[Rakotomandimby Mihamina (tech-infogerance)]

Have you got some link talking about that auto limitation of /tmp on Ubuntu please?

[Elias K Gardner (zorkerz)]

Everything I know about it is detailed on this bug.

[dei (cephos)]

Having the same problem again with jaunty final (upgraded from intrepid, now working with kernel 2.6.28-12-generic and ext3-Filesystem) My tmp free-space is getting smaller and smaller... :-(
Reopened the bug.

[dei (cephos)]

I forgot, I'm using 32 bit system...

[capnjack (mccachar)]

Just had this problem again. 32-bit 9.04 fresh install with all updates on HP DL380G3. Built the machine just to run scrub against some drives to see if any were dead. Drives filled, I rebooted, deleted all the scrub files (so there's about 93GB free) and went to HP's site to download some firmware, which failed due to lack of temp space. "overflow" was mounted at /tmp with a size of 1MB. Tried to "/etc/init.d/mountoverflowtmp stop", which doesn't actually remove that /tmp mount. "/etc/init.d/mountoverflowtmp start" just causes it to report a second mounting. Another reboot put things back to normal.

BTW, these are all EXT2 filesystems this time.

/dev/cciss/c0d0p1 on / type ext2 (rw,relatime,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,nosuid,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
lrm on /lib/modules/2.6.28-13-generic/volatile type tmpfs (rw,mode=755)
/dev/cciss/c0d1p1 on /disk1 type ext2 (rw,relatime)
/dev/cciss/c0d2p1 on /disk2 type ext2 (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/cmccabe/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=cmccabe)

Filesystem Size Used Avail Use% Mounted on
/dev/cciss/c0d0p1 101G 2.3G 93G 3% /
tmpfs 1.9G 0 1.9G 0% /lib/init/rw
varrun 1.9G 108K 1.9G 1% /var/run
varlock 1.9G 0 1.9G 0% /var/lock
udev 1.9G 148K 1.9G 1% /dev
tmpfs 1.9G 88K 1.9G 1% /dev/shm
lrm 1.9G 2.2M 1.9G 1% /lib/modules/2.6.28-13-generic/volatile
/dev/cciss/c0d1p1 67G 52K 64G 1% /disk1
/dev/cciss/c0d2p1 68G 52K 64G 1% /disk2

Linux cmccabe-dl380 2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:57:31 UTC 2009 i686 GNU/Linux

Without taxing my under-caffeinated brain too much, can someone explain the point of mounting this puny /tmp in the first place? Is this a ramdrive so even if the disks are truly full, progs can still see "temp" space? I think the cure is worse than the ill. Furthermore, I think it contradicts what so many people like about the 'nix world: the straightforward approach. If the disk is full, the system should tell you the disk is full, not try to fake it so things half work.

Thanks,
Chaz

[joehill (joseph-hill)]

This is still a problem for me after upgrading to Precise. I believe my root partition filled up at some point, and ever since then, even after rebooting, my /tmp directory is 1MB max and has nothing to do with how much space is actually on the partition. None of my applications work now and everything crashes all the time.