Log files are good because they log stuff, so you can find out what’s been going on and troubleshoot. But they tend to accumulate and can actually fill up your hard drive. Most Linux distros have automatic log file management for common system logs, but if you are running something on your server that keeps a log not thusly covered, you may have to manage that log file by yourself.

You could have a cron entry that simply deletes the log files in question every week or so, but then you lose the benefits of having a log file to begin with. The usual solution to this is called “Log Rotation” and it works like this:

The usual solution to the space problem is to rotate your log files. (We’ll see an unusual solution later in this section.) After a specific duration has passed or a file size has been reached, the current log file is moved to another name, e.g., logfile.0. The logging process is then continued into an empty file. At the next interval or limit, we repeat the process, first moving the backup file (logfile.0 ) to another name (like logfile.1). This process is repeated until a set number backup files have been created. The oldest backup file at that point is deleted.

There’s a script or two here to make this work. Here‘s another script (scroll down to see it), and here‘s a bash script that uses cron to rotate log files.

Comments

  1. #1 Jonathan
    October 25, 2009

    Why not just use logrotate? (http://www.linuxconfig.org/Logrotate)

    Easy to manage different schedules for different logs, run commands before or after (e.g. to make an application reopen its logfiles)

  2. #2 Jonathan
    October 25, 2009

    As an addendum to the previous comment, this is what most distros use to manage their own logs (as you elude to in the post), but the rules for it are really not hard to write, probably easier than an adhoc script.