January 24th, 2006
Linux has powerful logging capabilities that can be invaluable when diagnosing a problem, but when left unchecked can amount to a sizeable amount of your hard disk being consumed. How big? Well when I was starting out with Linux a couple of years ago, I didn’t know that such detailed logfiles were being stored; so went along my merry way until one day I stumbled across a 300+MB messages file in /var/log/. The problem was that my computer was never on in the early hours of the morning when the logrotate cron job was set to go off.
As you can guess this is oriented towards Linux being used as a desktop, but feel free to edit parts of this as you go along to accommodate for a longer log-life. All the instructions in this post need to be run with super user privileges; so use sudo or su. First up is to edit the logrotate configuration file:
pico /etc/logrotate.conf
# For more details, see "man logrotate".
# rotate log files daily:
daily
# keep 7 days worth of backlogs:
rotate 7
# create new (empty) log files after rotating old ones:
create
# uncomment this if you want your log files compressed:
#compress
That’s how my configuration file is laid out: it creates a backup of all the log file daily and starts overwriting the first at day eight. You can test your configuration by going:
logrotate -f /etc/logrotate.conf
So what’s cron? cron or crond (the cron daemon) is like the Windows Task Scheduler. It uses a simple syntax to run your scripts automatically at a given time. To make it easier, it also provides the concept of run parts to run everything in a directory, so you don’t have to edit to accommodate for every single script you want to schedule. For instance if you want a script to run daily, just plonk it into the /etc/cron.daily/ directory and you’re done.
Of course the next logical question is when do the cron.daily scripts get run? Well they’re probably going to be running early in the morning when your desktop is turned off, so you’ll want to fix that by editing through a convenient little program called crontab. Crontab is basically the vi editor set up to edit cron files. Vi can be a pain, so if you’re not used to it have a look at this excellent quick reference. The run parts, that is the cron.daily/weekly etc. directories should be run as root, so edit through crontab:
crontab -e root
[snip]
# Run daily cron jobs at 20:40 every day:
40 20 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
[snip]
Now you’re done, just make sure you actually have the logrotate script in the /etc/cron.daily directory, and that it has executable permissions, if you don’t then it should go something like this:
cd /etc/cron.daily/
touch logrotate
pico logrotate
#!/bin/sh
/usr/sbin/logrotate /etc/logrotate.conf
ctrl-x yes
chmod 750 logrotate
January 25th, 2006 at 11:19 pm
Umm… wow? XD haha… I am so far beyond this technology it’s not even funny. But then again, I also grew up on a farm.
January 26th, 2006 at 12:34 am
Yea, I know that the logs can get quite large, but hey, my computer is on sometimes 24/7 in which case the cron job clean-up ought to do it’s work. And for those weeks when I don’t have it up at such early times I don’t really mind because I’ve got an 80 GB hard disk. Keep in mind though that all our music is shared at home over NFS and and my mail is all on the mail server.
Cute script though. Since I am here at the conf the dude beside me had a look at what I was doing and he suggested this thing called anacron which basically has a look at what time cron jobs are run at. Then for example, say you’re /var/logs clean-up runs at 04:00 in the morning while you’re sleeping and your system is off then it realises that when you turn your system on at say 10:00 the cron jobs are either run or run at a later desired time (iirc). Might do the trick too.
January 26th, 2006 at 1:29 pm
Aranil, the most I know about horses is that they have four legs and are mostly brown.