LinuxQuestions.org - [SOLVED] /tmp filling up very quickly

- Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)

- - /tmp filling up very quickly (https://www.linuxquestions.org/questions/linux-general-1/tmp-filling-up-very-quickly-925503/)

/tmp filling up very quickly

I have a new installation of Crunchbang RO20111125, and I allowed it to partition my drive. It created a 350MB /tmp partition which fills up rather quickly. The strange part is that I don't see a whole lot there. I've gone through every subdirectory and none of the files, including the hidden ones are very large. Even when I delete the entire directory, it still says it's full.

Any ideas?

What does:

Code:

du -h /tmp

say?

Also post output from:

Code:

# lsof +D /tmp

(Yes, that's a root prompt.)

well, since last I rebooted, it hasn't filled up but I don't see any difference in the present files.
What I thought was strange was that after I deleted everything in the temp directory "sudo rm -rf /tmp/*"
and "df -h" still showed 100% used

Here are the commands you asked for. Like I said currently it's not acting up.

dan@Mojo:~$ du -h /tmp
4.0K /tmp/.X11-unix
4.0K /tmp/ssh-fmKHbB1685
4.0K /tmp/.ICE-unix
4.0K /tmp/keyring-FTJ76Q
4.0K /tmp/plugtmp
4.0K /tmp/orbit-dan
32K /tmp

dan@Mojo:~$ lsof +D /tmp
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
gnome-key 1683 dan 5u unix 0xffff880147742280 0t0 7929 /tmp/keyring-FTJ76Q/control
nm-applet 1833 dan 12u unix 0xffff88014881c8c0 0t0 6733 /tmp/orbit-dan/linc-729-0-259bd9c41d4f1
nm-applet 1833 dan 13u unix 0xffff8801476798c0 0t0 8093 /tmp/orbit-dan/linc-729-0-259bd9c41d4f1
gconfd-2 1835 dan 11u unix 0xffff880147bdb780 0t0 8208 /tmp/orbit-dan/linc-72b-0-48ec680f9e09b
gconfd-2 1835 dan 14u unix 0xffff88013999aa40 0t0 59053 /tmp/orbit-dan/linc-72b-0-48ec680f9e09b
gconfd-2 1835 dan 15u unix 0xffff880147766080 0t0 8225 /tmp/orbit-dan/linc-72b-0-48ec680f9e09b
gconfd-2 1835 dan 16u unix 0xffff880147767400 0t0 4759 /tmp/orbit-dan/linc-72b-0-48ec680f9e09b
gconfd-2 1835 dan 20u unix 0xffff8801399f9840 0t0 10405 /tmp/orbit-dan/linc-72b-0-48ec680f9e09b
notify-os 1844 dan 14u unix 0xffff8801493921c0 0t0 8226 /tmp/orbit-dan/linc-734-0-77101ca1f0f34
notify-os 1844 dan 15u unix 0xffff880149675940 0t0 8228 /tmp/orbit-dan/linc-734-0-77101ca1f0f34
firefox-b 2051 dan 13u unix 0xffff8801399f9500 0t0 10176 /tmp/orbit-dan/linc-803-0-482f59a85d241
firefox-b 2051 dan 14u unix 0xffff880149674f80 0t0 10177 /tmp/orbit-dan/linc-803-0-482f59a85d241
/usr/bin/ 2708 dan 8w unix 0xffff88013999b400 0t0 56146 /tmp/orbit-dan/linc-a94-0-7e0e1c9c52091
/usr/bin/ 2708 dan 13u unix 0xffff88013999b0c0 0t0 56147 /tmp/orbit-dan/linc-a94-0-7e0e1c9c52091

You can post again the outputs of the commands if/when it fills up quickly.

Also, try that "lsof" command again but without the "+D" option, and look for large deleted files that some process is holding open.

(And do it as root next time, like I mentioned. BTW, +D recurses to all children directories. I'd think that would be preferable for analysis.)

The +D option uses the directory tree to find files, and thus will miss any deleted files.

Code:

# lsof /tmp | grep -i del

lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/rnichols/.gvfs

      Output information may be incomplete.

gnome-ter 2673 rnichols  23u  REG  0,18  295057 55191627 /tmp/vtePQX67V (deleted)

gnome-ter 2673 rnichols  24u  REG  0,18  337813 57403840 /tmp/vte59DB8V (deleted)

gnome-ter 2673 rnichols  25u  REG  0,18  100368 57403841 /tmp/vte6ODB8V (deleted)

gnome-ter 2673 rnichols  26u  REG  0,18    4880 60981331 /tmp/vteUTKA8V (deleted)

gnome-ter 2673 rnichols  30u  REG  0,18    85920 55191628 /tmp/vteXIX67V (deleted)

gnome-ter 2673 rnichols  31u  REG  0,18    81056 55246675 /tmp/vteBVJ57V (deleted)

# lsof +D /tmp | grep -i del

lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/rnichols/.gvfs

      Output information may be incomplete.

#

Indeed. Good catch. (I'd still run lsof(8) both ways next time the problem occurs.)

After deleting the files, try remounting the /tmp dir (must be root):

Code:

mount -o remount /tmp

Alternatively, instead of rm the files try removing the contents of the files in the /tmp dir

Code:

find /tmp -print0 -type f | xargs -0 -i > {}

Remember also that while a file is open, the directory information such as file-size will not be updated. Commands such as lsof (ls open-files...) can be useful.

I haven't had the problem again, not in the last couple of days. I'll keep you guys posted if something comes up.

I do have a question through. What is a good size for a /tmp partition

Unless you have "unusual" needs (i.e. an application that you know will be writing large files to /tmp), 1GB or a bit less should be plenty sufficient.

Quote:

Originally Posted by sundialsvcs (Post 4585928)

Remember also that while a file is open, the directory information such as file-size will not be updated. Commands such as lsof (ls open-files...) can be useful.

I wasn't aware of that. I know a file wouldn't update until it was closed but I never thought about the fact that it would affect the whole directory. That would explain while the available disk space wasn't updating.

to mreff555

if you delete some files in the future in the /tmp folder and the folder is still the same size, you can run the sync command by itself. Sync forces an immediate write of all updated data from buffers to hard drive.