> /dev/hdb3              12G   11G  1.5G  88% /
> /dev/hdb6             2.0G  868M  1.1G  44% /home
> 
> which seems fine... but nearly every day '/' gets up to 100% .. and can 
> be brought down to 88% by deleting /var/log/syslog .. meaning this log 
> file gets to about 1.5G in size.

Hmm. I went through an exercise recently (I get a big pile of news
nere). syslog and fetchnews (mainly due to that) tend to write fairly
*large* files when slogging down a big newsfeed. I originally had
/var on its own rather small partition (maybe 500 megs). It turned out
that well -- 500 megs wasn't nearly enough to use for /var, and 1.6 
gigs (/var/spool, on a separate older drive) was too small to use for
news.

So I moved things around, got rid of /opt (didn't really need it anyway),
and used the extra disk space. Plus I gave /var/spool its own slice
of disk real estate - 5 gigs (used to have /opt there) and turned 
the whole 1.6 gig drive over to /var, just becauase of those really
big logs.

There were several times when I had to do my own rotating - which
isn't all that difficult. You need to 'service stop syslog' to turn
the syslog service off (as root, btw) and also go into the /var/log and
gzip the rather large file. At the same time, you can move the old
log files out of the way. That's basically what the syslog script
does. For instance:

cd /var/log
rm -f biglog.5.gz
mv biglog.4.gz biglog.5.gz
mv biglog.3.gz biglog.4.gz
mv biglog.2.gz biglog.3.gz
mv biglog.1.gz biglog.2.gz
gzip biglog
mv biglog.gz biglog.1.gz
touch biglog

Then restart ('service syslog start') your syslog, and the space is
given back. And you don't have to blindly remove stuff in /var/log -
that approach may cause you to lose some log data that you will need.

Oh, and I've experienced times where there wasn't enough space on the
disk to hold the gzipped copy - so in that event, I would cp the log
files to /tmp, gzip them there and then mv out of /tmp to /var/log. :)


> What can I do to prevent this? tips? I don't really like the idea of 
> setting up a cron job to daily delete it! :)

That would be counterproductive - why delete logs that you just created
that day?

And the other suggestions - they too have merit. You might have to make
/var bigger, or symlink /var/log to /home. I don't particularly like the
latter, since it means that if you backup /home you get log files in the
backup too.

What you probably should do first is to try and narrow down what it is
that's creating such a big log file. Use 'tail' on it periodically to
find ouit what kinds of things it's writing there.


Want to buy your Pack or Services from MandrakeSoft? 
Go to http://www.mandrakestore.com

Reply via email to