keep a console open, and in it, have this running: tail -f /var/log/syslog
then you get a realtime updating window of whats being added to syslog.. then you can use all your usual apps and see what they are adding. rgds frank -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of dfox Sent: Wednesday, 5 June 2002 11:22 AM To: [EMAIL PROTECTED] Subject: Re: [newbie] disk space advice > /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