Linux: Flexible log rotation

The logrotate facility provides an automatic way for log files to roll over, basically ensuring that they don’t grow so large that they consume too much space on your disk. This also makes them more amenable to searching unless, of course, you need to look back over a very long time range. With adequate disk space, however, you can store enough data to provide a useful long-range view of what’s going on with your systems.

On most Unix systems, you will find 5 to 7 messages files with names like messages, messages.1, messages.2 and so on. Whether the logs roll over every day (giving you about one week’s worth of log data) or every month, on the other hand, makes a huge difference in how big the files get and how much data remains at your fingertips.

Often the files roll over whenever /var/messages reaches a certain size. However, the number of files that are retained, the criteria used to determine when the logs are rotated, and even the naming of the files depends in part on how the logging facility on your system is configured.

There are also many types of log files that your system is likely keeping for you. Here’s a sample /var/log/directory showing all the log types stored on this particular system. Notice how many different logs are rolled over four times before the oldest files are removed altogether.

$ ls /var/log
acpid            cron.3          maillog.3   secure     vbox
anaconda.log     cron.4          maillog.4   secure.1   vsftpd.log
anaconda.syslog  cups            messages    secure.2   vsftpd.log.1
audit            dmesg           messages.1  secure.3   vsftpd.log.2
boot.log         fail2ban.log    messages.2  secure.4   vsftpd.log.3
boot.log.1       fail2ban.log.1  messages.3  spooler    vsftpd.log.4
boot.log.2       fail2ban.log.2  messages.4  spooler.1  wtmp
boot.log.3       fail2ban.log.3  mysqld.log  spooler.2  wtmp.1
boot.log.4       fail2ban.log.4  pm          spooler.3  yum.log
brcm-iscsi.log   faillog         ppp         spooler.4  yum.log.1
btmp             httpd           prelink     squid      yum.log.2
btmp.1           iptables.log    rpmpkgs     tallylog   yum.log.3
conman           lastlog         rpmpkgs.1   up2date    yum.log.4
conman.old       mail            rpmpkgs.2   up2date.1
cron             maillog         rpmpkgs.3   up2date.2
cron.1           maillog.1       rpmpkgs.4   up2date.3
cron.2           maillog.2       samba       up2date.4

If you see something like this when you look at your messages logs, you’re obviously rotating on a weekly basis.

$ ls -l /var/log/messages*
-rw------- 1 root root   46 Sep 28 04:02 /var/log/messages
-rw------- 1 root root  733 Sep 26 10:01 /var/log/messages.1
-rw------- 1 root root 5675 Sep 17 04:05 /var/log/messages.2
-rw------- 1 root root 4676 Sep 11 12:46 /var/log/messages.3
-rw------- 1 root root  354 Sep  4 20:39 /var/log/messages.4

Alternately, you can just take a look at your /etc/logrotate.conf file or run a command like this that shows you are using more than one frequency setting:

$ egrep "daily|weekly|monthly|yearly" /etc/logrotate.conf
# rotate log files weekly
weekly
    monthly
    monthly

Some systems will rotate wtmp (logins) and btmp (failed logins) files on a monthly basis rather than a weekly basis to keep more of that data around.

The primary configuration file for logging is the /etc/logrotate.conf file. It contains your “daily”, “weekly” or “monthly”. The logrotate command, which actually performs the log rotation might be /etc/cron.daily/logrotate, /etc/cron.weekly/logrotate, or /etc/cron.monthly/logrotate — depending on your log rotation frequency settings.

The logrotate command that is used probably looks like this:

/usr/sbin/logrotate /etc/logrotate.conf >/dev/null 2>&1

We can see that this command reads the main configuration file and tosses all of its output to the bit bucket.

The section for wtmp files might look like this. Here, we see that the rotations are monthly, that the files are not rolled over unless they’re at least 1 MB in side, that the rolled over logs will be set to 664, owner set to root, and group set to utmp.

/var/log/wtmp {
    monthly
    minsize 1M
    create 0664 root utmp
    rotate 1
}

Also for /var/log/wtmp, we’re only retaining one rolled over file (rotate 1), so we’ll never see more than /var/log/wtmp and /var/log/wtmp.1.

If size is an issue, you can also elect to compress log files when they are rolled over.

Add “compress” in your /etc/logrotate.conf file and your files will be compressede using gzip. Prefer another compression tool? That’s not a problem either. Use the compresscmd option to specify the tool you want to use.

compresscmd /usr/bin/bzip2

The dateext option will give you the rotation date as your file extension rather than a number like 1 or 3. Your log files will have names like messages-20140929.

There are numerous other options that you can use within your logrotate.conf file. You can, for example, specify scripts to be run before or after log rotation and specify what should happen if your log files are empty when the logrotate command is run. Take a look at the man page if you’d like to what some of the other options are.