Cleanup tmp?

[Markbnj]

Hi guys. Today I started having problems with a debian server I have that runs on our home network. The machine runs bind9, squid, and squidGuard, and that's pretty much all it does. The squid proxy started to get flaky. The kids could connect sometimes, and others not, and image links were often broken.

I logged on the server and went to clear the mailbox as usual and received a message "mail: /tmp: No space left on device".

Here is the output from df:

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda1 6728280 6395184 0 100% /
tmpfs 514268 0 514268 0% /lib/init/rw
udev 10240 72 10168 1% /dev
tmpfs 514268 0 514268 0% /dev/shm
/dev/hda6 106063388 43659152 57016440 44% /home
/dev/hdb1 57691772 1191900 53569216 3% /hdb1

I'm not sure what normal looks like, but it appears like I have run out of room on hda1. Are there things I should clean up, or should I just edit fstab to mount /tmp on another partition?

 

[Crusty]

fwiw, you can run df -h and it'll spit out numbers that are easier to digest.

I would first figure out what's hogging up all the space in your root. You can use the tool du to scan the filesystem and spit out file and directory sizes. For example, to find out the size of your /var directory you would run 'du -sh /var'. That will tell you the total size of all files and sub-directories under the /var directory.

I would guess that your proxy caches might be getting larger then you think or you have a runaway log file. All of which should be located under /var, unless you've specifically changed their storage locations.

As far as mounting /tmp on a different partition, that's always a workable solution. I usually mount /home /var and / with their own partition and just leave /tmp on the / partition.

 

[crontab]

your / file system is full. You don't have /tmp as a separate file system so it seems like it's on /.

if you see unwanted files in the /tmp directory, remove them

also if you have large logs or old logs in /var/log, you should remove them if you don't need the content anymore.

I use du -kx | sort -n | tail to see the largest offended directory

also find / -size +9999 -ls to see what the large files are

 

[n0cmonkey]

Look at /var too.

cd /
du -hs /var /tmp

 

[JD50]

cd to /
then do "du -h --max-depth=1" and start tracking down the culprit. My bet is it's something in /var.

 

[Markbnj]

Ok guys, thanks for the recs. I did look at /var/log and there aren't any massive files in there. Squid is supposed to use a fixed amount of disk for cache, and its cache is actually on hdb1, not hda1, so I don't think that's it either.

Time to go digging around some more I guess.

Edit: hey n0cmonkey, good to see you around. Seems like it's been awhile.

Edit2: heh, 3.8GB in /var... so I guess I know where to look.

Edit3: I have 1.1 gig in /var/cache/apt, most of it in a subdir called archives. What's the story on this stuff?

Edit4: so what's the feasability of moving /var in entirety to another partition? I googled a bit and seems there is or was a problem requiring /var/lock and /var/run to stay on root. Is it worth trying this, or perhaps I should just move /var/www (where about 50% of the fat is) over to the other disk and drop a symlink, or edit apache to move the root.

Edit 5: I think I'm just going to boot with gparted and resize hda1. There is plenty of space on that disk. I don't recall why root was set to just 6GB, but I think I accepted whatever the default partitioning choices were. I relocated the web root to hdb1 for now, which freed up 1.5 gigs. The other two big chunks on hda1 are /var/cache/apt/archives, and /usr. I think I will mount /user on hdb1 as well, after I resize. That should be easier to move than var I would think.

 

[JD50]

/var/cache/apt/archives is where all of your downloaded packages are stored whenever you use apt-get. I hardly ever use distros that use apt-get, but I believe something like "apt-get clean" or something like that clears our your cache. Check out the apt-get, apt, aptitude (whatever) man pages for more info. You could probably just manually delete everything out of that directory, but apt-get might not like that.

 

[Markbnj]

Hey thanks, that apt-get command worked great. After that, relocating the root web folder, and moving /usr over to the other disk I am down to 22% utilization on that partition. Thanks a lot for the help, folks.