What a Wicked Web We Weave

Not many can claim to be more popular in web circles than the leader of all things HTTP: Apache. Figure 6 shows an example profile for Apache with some new options. The old compress option is the friendly disk space-saver. This option clearly should not be run on large logfiles if your server's CPU is creaking at the seams already; just schedule logrotate out-of-hours to solve any time-sensitive, heavy load problems by adjusting cron execution times. As is often the case, I'm comfortable ignoring missing files (missingok); also, I'm looking for 52 weekly logs.

Figure 6: Logrotate config for Apache on a Debian server showing some new config options.

The new delaycompress function is intriguing, especially if you need to access a file with a log-watching tool, such as the truly extensible Fail2ban package. The meaning of this config option is simple: Not only does it decrease the number of times compression takes place (initially at least), it might save a bit of CPU time in some circumstances, especially if your servers experience no quiet time. However, if another application can't work correctly because a logfile is compressed, then you can hold off gzipping the file in question until the next rotation. Although I haven't looked, I suspect Fail2ban has addressed this issue because it's so configurable.

Let a Computer Do the Work for You

As I mentioned earlier, one prerequisite of a healthy file is correct permissions. In the past I've had some success running

# touch /var/log/<daemon-name>.log
# chown owner:group /var/log/<daemon-name>.log
# chmod 640 /var/log/<daemon-name>.log

after moving or renaming a logfile in a graceless fashion. The hope was that I wouldn't see any application downtime caused by restarting my service to fix empty logfiles as a result of an application that couldn't write to the file correctly after a logfile was moved.

However, the graceful way of achieving this via logrotate is to use the create config option, as in:

create 640 root adm

If you compare my manual command-line entries and logrotate's automated approach, the config option should make perfect sense.

In Figure 6, the purpose of the sharedscripts option encapsulated within the curly brackets in line 8 might not be immediately obvious, which brings me to the prerotate and postrotate config options. As logrotate runs through profiles, the prerotate and postrotate options are processed for each and every logfile being rotated.

Sometimes file name patterns lead to several logfile matches (especially with an errant wildcard here or there); therefore, the prerotate and postrotate config options can run multiple times, and if the postrotate option starts and stops a daemon, you could be restarting your previous web application several times unnecessarily, among other unneeded activities. The friendly sharedscripts parameter lets you specify that these kinds of actions are triggered only once.

For those of you who are familiar with Bash scripting, note in the Apache example that the prerotate option checks for the existence of a directory (i.e., httpd-prerotate) where fully configurable precursor commands can be applied should additional configuration be needed.

You Say Tomato

It might sound a little strange but there's method to the madness of having a favorite file compression utility. Some formats, utilities, encryption ciphers, and time frames dictate that you need to make choices about zipping, gzipping, or adding obscure command-line parameters to the compression options within logrotate.

To this end, you have the ability to affect how you squash your logfiles to keep the ever-precious storage freed up by using:

compresscmd zip

An option I've found very useful is dateext. When you first see the logfiles generated by an automated log rotation system, it's easy to mix up which is the oldest and which is the latest files in the list. Figure 7 shows this a little more clearly, and it's easy to spot the newest because dpkg.log.1 isn't compressed with gzip. You can still see why files numbered 1 to 12 without many differentiating features could be confusing, however.

Figure 7: If it weren't for color coding, it might not be immediately obvious which of the numbered logfiles is the newest.

The useful dateext switch lets you add dates to the end of rotated logs instead of simply numbers. The format YYYYMMDD can be changed conveniently with the dateformat parameter, which apparently conforms to the strftime command. However, it only supports year, month, and day specifiers (%Y, %m, %d, respectively). If you feel the need, though, you can throw in Unix time (or rather, the number of seconds since the Epoch – midnight on January 1, 1970) with the %s specifier. Both are very useful options to my mind; one date format for human eyes to scan quickly and another for a script to scrutinize.