Logrotate

Rotates log files weekly and saves a predetermined number of older logfiles. Deletes expired logfiles.

/etc/logrotate.conf:

Basically, this configuration file should not be changed, except for global options. All additions to logrotate should be done in /etc/logrotate.d. Here is an example of a basic logrotate config file:

     # see "man logrotate" for details
     # rotate log files weekly
     weekly
     # keep 4 weeks worth of backlogs
     rotate 4
     # create new (empty) log files after rotating old ones
     create
     # uncomment this if you want your log files compressed
     #compress
     # RPM packages drop log rotation information into this directory
     include /etc/logrotate.d
     # no packages own lastlog or wtmp -- we'll rotate them here
     /var/log/lastlog {
         monthly
         rotate 1
     }
     /var/log/wtmp {
         monthly
         create 0664 root utmp
         rotate 1
     }
     # system-specific logs may be also be configured here (although, we put them
     # in /etc/logrotate.d).

/etc/logrotate.d/xxx:

You should use individual files, in the same manner that the RPMs do, to describe rotation information for your system-specific log files, instead of monkeying with the top-level logrotate config file. You can create as many as you wish in the directory "/etc/logrotate.d". What follows are some examples of common ones.

/etc/logrotate.d/clamav:

     /var/log/clamav/*.log {
         missingok
         notifempty
     }

/etc/logrotate.d/fetchmail:

     /var/log/fetchmail {
         missingok
         notifempty
     }

/etc/logrotate.d/guidedata:

     /var/log/guidedata {
         missingok
         notifempty
     }
     /var/log/tivo.log {
         missingok
         notifempty
         create 0666 root root
         copytruncate
     }

/etc/logrotate.d/mailrobot:

     /var/log/mailrobot {
         missingok
         notifempty
     }

/etc/logrotate.d/narc:

     /var/log/firewall {
         missingok
         notifempty
     }

/etc/logrotate.d/robot:

     /var/log/robotdb {
         missingok
         notifempty
     }

/etc/logrotate.d/samba:

It appears that on some of the older installations of Samba the installed logrotate file is incorrect (some log files are missing). The incorrect file reads:

     /var/log/samba/*.log {

The corrected line should be:

     /var/log/samba/log.nmbd /var/log/samba/log.smbd /var/log/samba/*.log {

Without this correction, the log will not be rotated properly (it took mine two years to fill up).

However, newer versions of Samba have corrected this problem by getting rid of the log.nmbd and log.smbd files. So, if your version of Samba doesn't use these files, there's nothing to change.

/etc/logrotate.d/sendmailfilter:

     /var/log/sendmailfilter {
         missingok
         notifempty
     }

/etc/logrotate.d/ups:

This file rotates all of the logs associated with the UPS monitoring package NUT. Here are three examples of individual UPS logfiles being rotated:

     /var/log/upslog.Mast {
         notifempty
         missingok
         create 0664 root ups
         copytruncate
         postrotate
             echo HEADER: Mast >/var/log/upslog.Mast
         endscript
     }
     /var/log/upslog.Nova {
         notifempty
         missingok
         create 0664 root ups
         copytruncate
         postrotate
             echo HEADER: Nova >/var/log/upslog.Nova
         endscript
     }
     /var/log/upslog.Tokamak {
         notifempty
         missingok
         create 0664 root ups
         copytruncate
         postrotate
             echo HEADER: Tokamak >/var/log/upslog.Tokamak
         endscript
     }

/etc/logrotate.d/yum:

If either the automatic software update daemon yum-updatesd is used or if yum is invoked manually, it will write a log entry for each package that it installs, updates or deletes to its logfile. Unfortunately, the log entries are only stamped with the month and day, not year, when they are written.

Having log entries that are not stamped with their year of occurrence is not a problem except for the fact that the frequency of software updates is often quite low and the size of the log entries is so small so that the logfile doesn't grow at a very fast rate. In an effort to not create too many tiny-sized logfiles, the author of the yum module in logrotate.d set a minimum size for rotation.

The mimimum size for file rotation probably seemed like a good idea at the time but one must consider that it could be possible for a whole year's worth of updates to fit into a single logfile. Thus, in certain circumstances, part or all of a second year's worth of software updates could be added to the end of the logfile.

Normally, this wouldn't be a problem if only humans were reading the logfile but, if an automatic log reading program such as logwatch is employed, the lack of years in the log entry timestamps, coupled with the fact that the logfile can roll over to more than a year's worth of data, means that, once a year elapses, logwatch can begin to generate reports about last year's software updates.

The typical rotate module, installed along with yum, reads:

     /var/log/yum.log {
       missingok
       notifempty
       size 30k
       create 0600 root root
     }

We prefer an altered module that reads:

     /var/log/yum.log {
       missingok
       notifempty
       yearly
       rotate 100
       create 0600 root root
     }

This will rotate the logfile yearly, unless it is empty. The chances that it will grow too big (e.g. a couple of megabytes) in a year are slim and none. Of course, what we'd really like to do is rotate it yearly or if its size is greater than some limit but you don't get that choice with logrotate.