Setup of a Logrotate File

Well, this one is probably not new to most people. Still, I would like to write down what I have learned about it.

The basic setup of such a config file is:

/path/to/file/that/should/be/rotated {
    ...
}

Within one Logrotate Config file, multiple such file definitions can occur.

Instead of ..., we essentially define a set of configurations, each configuration receives their own line. Examples for some such configurations:

  • Frequency: hourly, daily, weekly [weekday], monthly, yearly - This defines how often the file should be rotated. Not too surprising: daily means that the file will be rotated once a day. For weekly, there is an optional weekday specified - where the default is 0 and means sunday. There is also weekday 7 which means that the logfile is rotated after seven days, irrespectively of the weekday.
  • Size: size [size]. The log file is rotated if it is larger than the given size. Can be 1k or 1M or 1G, for Kilobytes, Megabytes or Gigabytes.
    Note that size and a timely rotation are mutually exclusive. The last specified option takes precedence.
  • missingok - If this file does not exist, then don’t raise an error.
  • compress - If rotated logfiles should be rotated. The command for compression can be specified via compresscmd.
  • delaycompress - From what I have seen in nginx log files, this does the following:
    • The access.log file stays uncompressed - which makes sense.
    • access.log.1 also stays decompressed.
    • Everything else, starting from access.log.2, will be compressed. In particular, the files will then be called access.log.2.gz, as the compression happens with gzip.
    • Use Case: Logrotate proposes the use case that a program cannot be told to close it’s logfile and hence continue writing to the old logfile.
  • rotate 30 - Keep the last 30 logfiles. Remove the 31st.
    I will still have to find out what happens if I change that? So for example, assume that I have got 30 old logfiles, and then I change my logrotate configuration to rotate 10. Will the only the first 10 logfiles be rotated, and access.log.11 up to access.log.30 will be kept forever? Not yet sure.
  • notifempty - If nothing was written in the file, then don’t rotate the file. Note that this different from missingok: notifempty is important for files where not a lot happens, missingok means that the file might not exist at all.
  • postrotate - This one is a bit more complicated. It’s syntax is:
    postrotate
  # Please do something!
endscript
    The script between postrotate and endscript is executed with /bin/sh after the rotation. Note that you may not expect a specific working directory! Also, the calling user group is a bit unclear to me.
  • prerotate - The before rotating equivalent of postrotate.

These are the probably most important options. If you are interested in all the options, run man logrotate in a terminal.

File Location

These files are typically located in /etc/logrotate.d/. You can also find a set of examples there.

Calling Logrotate

On a typical system, Logrotate is called by default once a day (see for example the /etc/cron.daily/logrotate file, altough the call is newly done via a Systemd timer).

If you still want to run logrotate by hand, the typical call is:

logrotate /etc/logrotate.conf

Another interesting option you might consider is logrotate -d - in this case, you get a lot of output, but nothing is actually done.

Logrotate Status

Logrotate stores a status about the files it should rotate. This status is stored in the file /var/lib/logrotate/status. I was a bit confused about Logrotate’s behavior, until I found this file.

Essentially, for every file that Logrotate should rotate, there is a line in this status file with the syntax

"/path/to/file" YYYY-M-D-H:m:s

It stores the time when this file was last rotated. And here’s the curious thing: If the file was not yet rotated at all, then the last rotation time is assumed to be kind of “now”, to the last full hour. So if you run logrotate today at 9:45 then you will get the information that this file was last rotated today at 9:00. This gave me quite a bit of confusion.
But still, this time is written into the status file and hence from now on, the defined rotation will happen.

My most important learning about the status: Assume you have a new logfile and you now define a logrotate concept for it. You define that the logfile should be rotated daily. Now my natural assumption would be: If I now execute logrotate, then the logfile should be rotated - as it is definitely older than a day.
Turns out, this is incorrect. The file will be first added to the status file right now (or, at the first proper logrotate run after configuring it). And then, a day later, this file will first be rotated.
So file rotation does not depend on the file create time, it exclusively depends on Logrotate’s status file.