Recently someone asked me about an issue he was facing with his Ubuntu Hardy Heron installation. Many of the applications, that he regularly used, were misbehaving. e.g., he couldn’t play flash videos in firefox, downloads were failing, installation of new applications were failing, etc. Everything was giving errors of not enough disk space even though he had quite a few GBs left on his drive. A few of the error messages pointed out that there wasn’t enough space in /tmp. And indeed, he was unable to store anything more than 1 MB inside this particular directory. After a quick look I found out the issue. Ubuntu had created another partition with /tmp being its mount point and its maz size was set to 1 MB.
A search told me that this occurs if you happen to run out of disk space on your root partition some time, so Ubuntu automatically limits the size of /tmp to squeeze as much out of the remaining space as it can. Ideally, original behaviour of /tmp should be restored once you recover some space but it doesn’t happen. The solution? Well, it is pretty simple. Just follow these steps.
Step 1. Open up /etc/mtab in your favourite editor. e.g.
gksudo gedit /etc/mtab
Step 2. Look for a line that looks something like below example and delete it.
overflow /tmp tmpfs rw,size=1048576,mode=1777 0 0
Step 3. Save the file and restart your computer. That’s it.
Now, this problem might not just be Ubuntu specific though and might happen with other distros as well. So, if you come across such an issue, try out this solution.[tags]Ubuntu, tmp, tmpfs, 1 MB /tmp problem[/tags]
Better still to leave the line and just remove the “size=#######,” which will allow your tmp directory to grow to half of your available ram (available at startup).
I actually add the line above and set the size manually to one-half ram _plus_ one-half configured swap space.
For various reasons having your /tmp drive self-clean between boots and completely ram based will greatly increase the speed of many operations. (e.g. an install that “copies through” /tmp wont become a disk-to-disk copy operation unless it _must_ overflow into swap).
Many distros put /tmp into a tmpfs (hence the name tmpfs
by default, and unless you are _pressed_ for ram, you should too.
Many applications which are not written properly, will generate errors about not enough room, when they actually do have enough room. What seems to happen is that people seem to think Linux is a 2 partition system: 1 partition for swap and 1 partition for filesystem. But if you actually have separate filesystems for /tmp, /usr, /usr/local, /var, /home, etc., more often than not the program in question is looking for freespace on /, and not in the filesystem where the room is actually needed.
@Rob: That is indeed a good suggestion.
@Gordon: You are correct. But there are many applications that actually need the space in /tmp and not just the final location. One example is as given by rob in a “copy through” install.
Thanks a lot !
my disk has been fulled by a wrong backup script.
After restoring things, I still have some database query that wasn’t outputing nothing and this error in the mysql error log
121222 10:28:38 [ERROR] /usr/sbin/mysqld: Incorrect key file for table ‘/tmp/#sql_33a3_0.MYI’; try to repair it
121222 10:28:38 [ERROR] Got an error from unknown thread, /build/buildd/mysql-5.5-5.5.28/storage/myisam/mi_write.c:223
I spend 4 hours debugging, thinking that I had database corruption after
I’ve read carefully this post
http://www.mysqlperformancetuning.com/a-fix-for-incorrect-key-file-for-table-mysql
And was convinced it was a tmp size problem though the error message of mysql didn’t point at all to this cause.
I hadn’t seen if tmp was on a specific partition before, but it was having a 1MB, very few in its own partition
In /etc/fstab they wasn’t any line for it
Furthermore the overflow that was printing when doing df -h was adding clue in this direction.
Your 2 steps recipe help got rid of this problem.
As ever, debugging is not funny, but by the way allow us to learn some interesting things about the os that run our sites.