I've only been running Linux for a year. Have been using Debian Squeeze since it was released. AMD64, ext4 for all partitions. During installation, I selected separate /home, /usr, /var, and /tmp partitions. If I recall correctly, the recommended size for /tmp struck me as too low, and I increased it. Gparted shows it as 380 meg. Every several weeks or days I get a message that

"Volume /tmp has only ??? Mb free"

and the computer is sluggish at those times.

1) I have little experience with Gparted to resize partitions, although I used to use Partition Magic. Is it safe to take several unused gig from /home to put into /tmp? I would, of course, only do that immediately after backing up.

2) Is there a better way to manage what stays in /tmp?

A bit of searching turned up methods to automatically search /temp for files old enough that they should not be needed any more (say, <3 days old). While it is possible to automatically delete those files, Linux in a Nutshell says that this can introduce security risks and advises manual deletion.

How can I learn more about what goes into /tmp, and what has to stay?

Thanks

You have /tmp on its own partition?

Yes. /tmp is a separate partition.

OK. Not sure why anyone would do that but it is your box.

Have you thought of just opening the /tmp file to see what is in it when this happens? I know you can get the details through your terminal but I like to look at things and see all the stuff as a whole.

What goes in there depends on what you are doing. Not sure what you would have to do to get it that large. Mine is currently at 32Kb. I have only been up for about a day though.

I have several installs for different reasons and rarely have this OS up for more than 3 days.
The gedit stuff is a 0bytes socket. The rest are directories 3 of which are empty.

The best way to manage your /tmp file is leave it in /.

As for making it bigger, you can most certainly do that. I have no idea what the possible size of it can be. You may find something about that with a search. I would do it in increments, probably to .5, .75 and then 1Gb. Surely 1Gb should do it unless you have a habit of doing a lot of intensive things at once for a long time.

I'd have thought 380 Mb would be large enough for /tmp in most cases.

I'm guessing this is a single user machine and there for it is *your* files that take up the space. You could consider setting the TMPDIR environment variable to somewhere with more space: Eg in your .bashrc add something like

many programs will respect that variable.

Another option would be to install tmpreaper (from package of same name) and configure /etc/tmpreaper.conf to your liking.

In terms of finding out what is using all the space: just look. du is your friend.
eg
Cheers,

Evo2.

Thanks for the replies.

This is a single user machine.
At this moment, I'm not having problems.
Nautilus shows

Type: folder (inode/directory)
Contents: 53 items, totalling 49.8 KB (some contents unreadable)
Free Space: 256.2 MB

Gparted shows

Partition /dev/sda8
File System ext4
Mount Point /tmp
Label TMP
Size 380.00 MiB
Used 104.84 MiB
Unused 375.15 MiB

Running in a terminal window

du -sckh /tmp/* | sort -h

shows

0 /tmp/OSL_PIPE_1000_SingleOfficeIPC_739726f52f1874ec7bae468785b1f
1.0K /tmp/kde-root
1.0K /tmp/kde-tom
1.0K /tmp/keyring-lVnlMC
1.0K /tmp/orbit-root
1.0K /tmp/plugtmp
1.0K /tmp/seahorse-rlWrjw
1.0K /tmp/ssh-lYzgMv2113
1.0K /tmp/virtual-tom.3qPGIt
3.0K /tmp/libgksu-CtzJlZ
3.0K /tmp/libgksu-lXQ2hP
4.0K /tmp/orbit-tom
12K /tmp/lost+found
25K /tmp/sv8an.tmp
55K total

The different values for how much of /tmp is being used are huge.

NO that is way way way too small
normally /tmp is a folder in the / partition

an example
Imagemagick stores images it is working on in /tmp
if you have a 500 meg image then Imagemagick WILL CRASH if you only have 320 meg of space in tmp

the /tmp folder is used by a LOT of programs
it needs to be big
that is why it normally in a folder on the / partition and not it's own partition

Do you really need to YELL?

Normally? Personally I'd hate to see my system bought to it's knees because of some program filling the / partition by writing a huge file to /tmp.

Pretty poor coding if that will cause it to crash. File a bug?

If users want temporary files that large they can set their TEMPDIR environment variable or configure the program creating the files to write them elsewhere. If the program doesn't provide ways to allow writing temporary files to another location it has a serious bug.

See above.

Evo2.

Hi,

Please show the output of:
If this differs from the du total there could be a number of reasons (the web is lousy with questions and answers on this topic).

Probably the most common cause is that a file is deleted while it is still open and being written to.

Evo2.

tom@Gigabyte:~$ df -h /tmp
Filesystem Size Used Avail Use% Mounted on
/dev/sda8 368M 98M 252M 28% /tmp
tom@Gigabyte:~$

Ok, so there seems to be about 98MB unaccounted for. Did you manually delete anything in /tmp?

Also, when you ran du on /tmp did you do so as root?

Evo2.

Both ways, nearly identical results.

The way I read it, 98 MB is used.

I manually deleted a few KB of files from /tmp a few weeks ago.

At this point, I'm wondering what Nautilus is actually displaying. I have thought that "/" (the root directory) covers the entire collection of hard drives on this machine, and that / is identical to "File System". However, given that GParted shows a separate /tmp partition, with a different size than Nautilus reports, I'm far from sure. So I'll probably shut the system down, and boot from a live distributions such as Mepis or System Rescue CD to see what it reports on my HD for /tmp. It is sounding to me as if there is a /tmp partition, and a /tmp directory in another partition. I could easily be mistaken.