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.