Making free space on /

[sabin]

Hello folks ^^

I have a problem : my free space on / passed from 950 Mo to zero bytes.
Let's summarize : I would like to know if there are ways to hunt unnecessary megabytes, and to reduce the /var/log size of the files.

I'm running Mandriva2006 in graphical mode.

Explanation of the problem
One of the possible causes of that problem is that a package update completely froze and had to be forcibly closed after ten minutes of inactivity. And the NFS thingie, at system shutdown, didn't close either after ten minutes waiting during shutdown, hence making me manually shutdown the computer. Next reboot, partmon said there was 0 byte free in /.
The graphical boot failed miserably as you can guess. But Linux amazed me, with zero free bytes the text-mode console worked
The only solution I found was to remove in console the largest of my packages, openoffice.org.
That package "weights" about 320 Mo, and with it removed, the computer could boot again... and now I'm supposed to have only 238 Mo free on /

Questions ^^
Would you know where the missing megabytes could have gotten lost ?

And how to free space on / ?
I have 1.3 GB in /var/log, including 440 MB for /var/log/syslog , 396 MB for /var/log/bandwith and 424 MB /var/log/kernel/info
I would be glad to remove them, but who knows, they might be necessary for the system. Could someone confirm me for sure that I can safely delete them ?

Help will be greatly appreciated, I would really want to reinstall openoffice, I don't have anymore access to my resume, excel sheets for my budget management, etcetera

[jpalfree]

Hey,

If you want to track down memory eating files you can try "du" it displays disk usage like so:

$ du -sh /*
7.8M    /bin
4.9M    /boot
296K    /dev
40M     /emul
44M     /etc
42G     /home
0       /lib
2.2M    /lib32
13M     /lib64
0       /mnt
287M    /opt
514M    /proc
9.5M    /sbin
0       /sys
74M     /tmp
320M    /var 

$ du -sh /var/*
97M     /var/cache
185K    /var/cvs
142M    /var/db
0       /var/empty
8.0K    /var/gdm
13M     /var/lib
0       /var/lock
5.7M    /var/log
0       /var/mail
49K     /var/run
0       /var/spool
0       /var/state
110M    /var/tmp

to my knowlege /var/log, /var/log/syslog and /var/log/bandwith are safe to remove since they are just log files. But hopefully someone will correct me if i'm wrong...

usually /tmp has some temporary files that don't get deleted. You could check that. I think pretty much everything under /tmp is safe to delete. but I usually like to be safe and only remove things when necessary.

[sabin]

Quote :
to my knowlege /var/log, /var/log/syslog and /var/log/bandwith are safe to remove since they are just log files. But hopefully someone will correct me if i'm wrong...

Yeah, I hope so too, that they can be removed safely ^^
But if that's not correct, imagine the mayhem that would cause, if I couldn't even boot my system anymore >_<

Would there be a way to just edit those files in order to empty them, instead of strictly deleting them, so as to change them into zero bytes files ?
This way the system would still find the (maybe) required files...
I don't think opening a 400 Mo file with kwrite or nano or vi would be the simplest solution to do that

[CodeRoot]

Here are a few examples of how to "zero out" files:

cp /dev/null /var/log/syslog

rm /var/log/syslog
touch /var/log/syslog

echo -n "" > /var/log/syslog

[Kojak]

to my knowlege /var/log, /var/log/syslog and /var/log/bandwith are safe to remove since they are just log files. But hopefully someone will correct me if i'm wrong...

If you are not running an enterprise server, you can remove them. They are only log files. Nothing more, nothing less. If there are important error messages or system warnings, you can backup those parts before deleting the files. And in /tmp, there is also some stuff that can be cleaned up. Another option to free up space is to clean the urpmi cache.
urpmi --clean
urpmi will collect quite a lot of stuff over the months, thus a cleaning now and then is a good option.

[sabin]

Thank you guys !

From another source (a linuxian friend on the phone ^^) I had a confirmation.
So I safely deleted those three 400++ MB of log files, and, i'm relieved, the system worked just fine again ^_^

However, you know what, I found what caused that inflation of the log files, syslog, bandwith and kernel/info...
Sometimes after I install a package in MMC's package manager, the software-install window, though working fine, won't reply as soon as I chose to close it (it will give a message such as "the window isn't replying", my OS is in French).
And sometimes in that case, that will cause the three files, syslog, bandwith and kernel/info, to grow as large as the free space will allow...

Weird, huh ?
But now I know how to solve that
Thanks ^^

[jpalfree]

here's a small script i wrote to check the /var/log directory ( or any other directory/files) and remove them when they are too big.
you can put it in one of your /etc/cron.... folders to execute weekly, monthly etc...
the variables let you customize it's behavior.

#!/bin/bash
#################################
# Script to check a directory and
# remove files that are larger
# in size than UPPERLIMIT
#
# by Jasper Palfree
#################################


#################################
# Variables
#################################

#directory to check
CHECKDIR="/var/log"

#files to check. eg: CHECKFILES="/var/log/Xorg.0.log /var/log/syslog
CHECKFILES="/var/log/syslog"

#in MB (at least 1)
UPPERLIMIT=10

# set to /dev/null if you don't want logging
LOG="/var/logchecker.log"

DATE="$( date +"%b %d %Y" )"
TIME="$( date +"%T" )"
START=$SECONDS

#################################
# functions
#################################
#checks size. arg is size given by du -sh
is_below_limit()
{
if [ $UPPERLIMIT -lt 1000 ]; then
echo $1 | grep "G" >/dev/null &&
return 1
fi

echo $1 | grep "K" >/dev/null &&
return 0

if (echo $1 | grep "M" >/dev/null ); then
local size=${1%M*}
size=${size%.*}
[ $size -ge $UPPERLIMIT ] && return 1
fi

return 0
}

# func to check disk usage in /var/log
checkdu()
{
for file in $CHECKDIR/* $CHECKFILES; do
if [ ! -d $file ]; then
local filename=$(basename $file)
local mem=$( du -sh $file | sed "s/$filename//g" )
is_below_limit $mem ||
RMLIST="$RMLIST $file"
fi
done

}

#removes files in $RMLIST
cleanup()
{
for file in $RMLIST; do
rm -v $file
done
}

###############################
# start
###############################

exec 1>>$LOG

echo "+++Cleanup of $CHECKDIR started on $DATE at $TIME"
checkdu

if [ "${RMLIST:=none}" == "none" ]; then
echo -e "\n+No files need to be removed"
else
echo -e "\n+The following files are scheduled for removal:"
for file in $RMLIST; do
echo -e "\t $(basename $file)"
done

echo -e "\n+Cleaning up files"
cleanup
fi

echo -e "\n+Time taken to complete: $(($SECONDS - $START)) seconds"
echo "+++DONE+++"

[sabin]

Thanks for the replies, everyone ^^

My bug is still present, but there's been development : it seems that actually everything going through my network card while my firewall is active becomes logged. Thus, with bittorrent and amule both running, it's between 300 and 500 kb of supplementary data written every second into three log files. Between 900 kb and 1.5 meg per second (When neither amule nor bittorrent are running, it will naturally grow much more slowly.)



I just made a script in order to make room easily, called "place"

#!/bin/bash
echo -n "" > /var/log/bandwidth
echo -n "" > /var/log/syslog
echo -n "" > /var/log/kernel/info

Code_root, thanks a lot, you provided me a script that won't ask a confirmation for every file ^^

As for your script, jpalfree, alas, if i'm not mistaken, cron can at best be ran hourly (and I don't even know how to use it ), and it would take less than an hour to fill my free space :/
The ideal for me, would be to be able to have the possibility to setup my script to be automatically ran every 15 minutes. Too bad that's not a possibility ^^

[jpalfree]

wow. sounds like a serious problem if it eats up your memory that quickly. ouch.

I'd recommend changing your script though. I may be mistaken, but I've heard that if you redirect output to a file it does not change the amount of memory allocated for it. IE: if you had a 1MB file and you did: echo -n "" > file.txt, then it would keep that 1MB allocated. Apparently the best way would be to do:

$ rm -f file.txt && touch file.txt

[sabin]

Actually, that script works ^^
When kwikdisk tells me there is zero free byte on /, after I run my script, there is once again between 1.0 and 1.1 free GB.

On the contrary, the command you gave me would require a confirmation.
So : first, run a script requiring root priviledge : one confirmation (password asked), deleting 3 files, 3 confirmations required...
I much prefer the current script only asking my opinion once ^^