Sample logrotate configuration and troubleshooting

Applying knowledge

A previous article Understanding the logrotate utility described what
logrotate does and how you can configure it. This article applies this
knowledge to creating a log-rotation solution for one or more custom virtual hosts.
It also identifies some options for testing and troubleshooting logrotate.

Tying it all together: virtual host logs

To show how you can use logrotate for your applications, here's an
example that will come in handy for many people: rotating logs for your
custom virtual hosts. The example uses Apache®, but you can tweak it
for other webservers like nNinx® or Lighttpd®, usually just by
changing the post-rotate script.

First, create a file to hold the configuration that tells
logrotate what to do with the virtual host's log files. Don't edit the main
config file or the webserver's config file because a future package upgrade might
want overwrite the configuration. Instead, make your own file with the following command:

/etc/logrotate.d/virtualhosts

This example tosses all the virtual hosts into one file, but if you have one host
that's busier than others you may want to create separate config files to handle
the needs of your different domains. The example specifies several items that are
probably already set in your main config, just to cover all the bases.

The files

Say you have two virtual domains, domain1.com and domain2.com, and
that the log files for each are in /home/demo/public_html/(domain name)/log.
Your config file needs to tell logrotate where to find the
log files, then start the config block for them:

/home/demo/public_html/domain1.com/log/*log /home/demo/public_html/domain2.com/log/*log {

If you have more log directories or files to add, insert them into that list.

Rotate

Next, make sure logrotate only keeps as many old logs as you want:

rotate 14

The example uses 14 files to keep two weeks' of logs, but you can
adjust that number to meet your needs.

Interval

Now, tell the webserver to rotate these logs daily (again, change it if
you prefer a longer interval):

daily

Size (optional)

The size setting specifies a maximum size for your logs. When the log reaches
that size, a log rotation is triggered.

size 50M

The size setting is optional here because it overrides any time-based
rotation conditions. You can specify both a time interval and a max size, but
if you do, logrotate ignores the time interval setting.

Compression

Specify whether you want to compress these logs when they're
archived. This example uses the delaycompress command to account for
the graceful restart of Apache, which means you also need to turn compression on:

compress
delaycompress

Sharedscripts

You might have several virtual hosts, and that would mean several logs to
rotate. To make sure the webserver only gets restarted after all the rotations
are done, add the following line:

sharedscripts

Postrotate

Specify a postrotate script to restart the webserver:

postrotate
        /usr/sbin/apachectl graceful > /dev/null
endscript

And finally, close the config block with a curly brace:

}

The whole file

Following is the complete configuration file:

/home/demo/public_html/domain1.com/log/*log /home/demo/public_html/domain2.com/log/*log {
        rotate 14
        daily
        compress
        delaycompress
        sharedscripts
        postrotate
                /usr/sbin/apachectl graceful > /dev/null
        endscript
}

Test the script either by watching things when the nightly cron jobs run or by running
logrotate manually with the following command:

/usr/sbin/logrotate /etc/logrotate.conf

If you don't get any errors back you should be okay. But if you want to be
certain you can run through some of the following tests.

Testing logrotate

If you suspect logrotate is having some trouble, or you just want to make sure a
new config you've put in place works, you can
pass some useful flags to logrotate when you run it from the command line:

Verbose

The verbose flag, -v, tells logrotate to say each operation it executes. This helps when you want
to find out why logrotate doesn't rotate a log as expected.

Debug

The debug flag, -d, tells logrotate to go through the motions of rotating logs
but not actually rotate them. It can be handy if you're working on a production server
and you want to test a new config file but don't want any actual log rotation run when you run the test.

Debug also checks that the config file is formatted properly and that logrotate can
find the log files it would rotate. However, since it doesn't run the
rotations, it doesn't test some parts of the process like the post-rotate scripts.

Force

The force flag, -f, forces logrotate to rotate all logs when it runs, whether
or not they would normally need to be rotated at that time. If you want to
thoroughly test logrotate's configs, this is the flag to use. Just remember that
logrotate rotates logs and deletes old ones according to the
configuration, so don't accidentally rotate out a recent log you
need to keep.

It can also be useful if you believe that logrotate should be rotating a log,
but it isn't. Forcing the issue helps you identify:

• If the problem is that logrotate doesn't think the log needs rotation (if you run the force flag
  and the log is rotated)
• If the problem is that logrotate isn't able to affect the log file (if you run it and nothing
  happens to the log).

Note: If you configured logrotate to add a date to the name of an archived log, not
even using the force flag makes logrotate create a new archive on the same
day. Because the name it needs to use for a second archive is already taken in that case,
you might need to rename the most recent archive before you can force a log rotation.

Combining flags

You can use the testing flags together quite effectively. To have logrotate tell
you what it would do if you made it rotate everything, but not actually rotate
anything, you can combine all three:

/usr/sbin/logrotate -vdf /etc/logrotate.conf

This command provides a long list of things logrotate would do, including which
log files it would rotate and what it would do during that process.

If you then want to test all the rotate configs in their entirety, including
the scripts run after rotations, you can run logrotate without the debug flag:

/usr/sbin/logrotate -vf /etc/logrotate.conf

Logrotate rotates all the logs. Skimming the output should help you catch any
obvious problems. You should also make sure that all your services are still
running okay, that there nothing wenr wrong with the postrotate scripts, and
that all the logs got rotated.

How logrotate remembers

If you find that a log isn't rotating even though it's old enough that it
should, manually run logrotate with the
-f flag. But if you want to know why something's gone
wrong, there's one more file you can check before forcing a rotation:

/var/lib/logrotate.status

Logrotate stores information about when it last rotated each
log file in the status file. If you look inside, you see something like:

logrotate state -- version 2
"/var/log/acpid.log" 2010-6-18
"/var/log/iptables.log" 2010-6-18
"/var/log/uucp.log" 2010-6-29
...

It's a straightforward format, the log file location is on the left, and the
date when it was last rotated is on the right. Sometimes, the
dates on your server get confused (if you were tinkering with an NTP
service or the like), and the date when a log was last rotated winds up being a
future date. If that's happened, you see it in this status file.

If you want to check logrotate out with a particular log file but don't want to
force everything to rotate, you can delete the log's entry from the logrotate
status file. Then when you run logrotate normally it should create a new entry
for the log with today's date (even though it may not actually rotate the log -
it uses that first run as a baseline if it's just interval-based).

Summary

For something that runs quietly in the background and only really performs one
type of task, logrotate does quite a bit. You should be able to set up new
logrotate config files for your own purposes, either creating them from scratch
or copying existing configs and modifying them appropriately. And most
importantly, you can keep your logs from getting out of control.