How Very Apt

As you might suspect, residing inside the logrotate profile /etc/logrotate.d/apt/ are the Apt package manager config files. Dpkg also has its own profiles with quite different config options (e.g., look inside /etc/logrotate.d).

In Figure 2, you can see that two otherwise relatively obscure logfiles relating to the Apt package manager are rotated and compressed. Moreover, no errors are generated if a log isn't present to rotate or is empty (notifempty).

Figure 2: Logrotate's bundled profile for the Apt package manager.

It's worth mentioning that the good old hash symbol will let you put comments into the profiles for each application, which can be useful if you've tried something new with your logs, left it running for a few weeks, and then returned to revert those changes. In the case of both term.log and history.log, the reliable logrotate will dutifully create and then rotate 12 monthly logfiles before deleting the oldest.

Clearly, you can easily deploy such profiles for other applications. Simplicity is always the way to fix complex problems in my book, and logrotate certainly doesn't fail to impress with its straightforward configuration options.

Making a Move

Now I want to look at profiles for other packages, some of which are popular and explained in the logrotate man page [1] if further information is needed. For clarity, I want to extol the simplicity of tidying up after changing the state of a logfile.

If you've ever tried manually shuffling logfiles and forgotten, or not realized, that you need to stop and start the service relating to that logfile after doing so, then you wouldn't be the first admin be caught out. That embarrassing moment when you return to your well-needed logfile a few days later to discover it is empty is never welcome. Rest assured that it's an easy mistake to make in a hectic environment.

A safe rule of thumb is that when an application starts up, it first needs to have write permission to the logfile directory (in the case of the two Apt examples, this directory would be /var/log/apt and not the more common /var/log). Second, it needs write permissions for the logfile in question. If the pertinent logfile is suddenly and forcefully renamed or moved to another location, then the application can simply appear to be running perfectly normally but in fact not be logging at all.

The examples in Figures 3 and 4 show two quite different restart options, neither of which uses the now common service <package> restart syntax or the old faithful /etc/init.d/<package> restart format. In the rsyslog example, you'll see that this example refers the Ubuntu-style [start|stop|restart|reload] syntax, where the action can be written without placing service at the front.

Figure 3: Restarting an application after moving logfiles around.

Figure 4: Another example of restarting a syslog service after rotating a logfile.

Parameters Aplenty

The eagle-eyed among you will have spotted in Figures 3 and 4 the postrotate parameters, under which the restart commands are nested. As you can probably guess, postrotate succinctly says to logrotate and, once done, finish by doing the tasks that follow.

A quick word of warning is that although wildcards are supported, you should approach them with caution because a misplaced asterisk will rotate every single file in a directory, breaking some (if not many) functions of varying importance. Although it will be easy to spot what has broken your application after a restart, point logrotate at the wrong place with a misplaced question mark or asterisk, and downtime could be in the cards. However, using *.log is a convenient and safe approach.

One of the logrotate parameters that always jumps out is the olddir command. For example, if

olddir /var/log/older/<daemon-name>

is inside the curly brackets of a profile but not nested within other commands and the olddir directory resides on the same disk as your main log directory, then the super-tidy logrotate will move old logs into this directory. This could mean that in /var/log you just see your current files instead of a host of backup, older file names, helping clarify what should and should not be considered current. I like this functionality because I'm almost always looking at the newest logfile first before delving further into older logs for trickier issues.

At this juncture, it's worth mentioning /etc/logrotate.conf, because it contains a few non-standard config options. The sections that catch my eye are shown in Figure 5. wtmp contains historical data about user logins and logouts, the terminals at which they occur, and other system events like reboots. btmp only records failed login attempts. The create lines create new logfiles owned by user root and assign permissions.

Figure 5: Configuration file /etc/logrotate.conf showing a global config setting and logrotate's uncanny ability to take care of wtmp and btmp logging as well.