How to Manage Your Log Files with Logrotate

Sign up for BitLaunch today and optimize your server with Linux Logrotate.

Over time, servers accumulate a lot of logs, especially those created by system processes. These can be invaluable if you're looking for information, but Linux servers can keep various log files past their relevancy. Logrotate was created to help users manage those system process logs, saving both SSD space and the resources required to write them.

The tool gives server admins control over how long logs are kept, when the system processes log rotation, and more. Theoretically, this should mean that the resource hit is minimized but required data is still maintained.

In most distros, Logrotate's behavior is managed via a logrotate config file that exists in /etc/logrotate.conf . We're going to be using Ubuntu 20.04 Logrotate throughout this tutorial.

How to Configure Logrotate

Though the primary Logrotate config file is located at /etc/logrotate.conf, most of the changes will in reality be made to files in /etc/logrotate.d. This is because the directory contains files and configurations for every log file or daemon process for individual configuration.

These are then loaded into logrotate.conf, which you can see by its line include /etc/logrotate.d. logrotate.conf also contains some global options for log files. When drilling down into individual log configs in /etc/logrotate.d, you should see Logrotate examples like this:

/var/log/nginx/*.log {
daily
missingok
rotate 52
compress
delaycompress
notifempty
create 640 nginx adm
sharedscripts
postrotate
		if [ -f /var/run/nginx.pid ]; then
				kill -USR1 cat /var/run/nginx.pid
   		fi
endscript}

By default, our nginx logs are set to rotate daily, rotating a log 52 times before old logs are removed and performing a  compress task on old logs, which is delayed until the next time the log is rotated. The log files are created with permissions of 640 with the user of nginx. The postrotate script runs a script after log rotation, such as a process restart, with sharedscripts telling Logrotate to check all the blocks for the configuration block and only run postrotate once if one of both of the logs is rotated. prerotate can be used to run a script before a rotation begins.

If necessary, then, we could set nginx logs to weekly, monthly, or yearly to suit our preferences. On a weekly rotation, logs get rotated if the day of the week is earlier than the weekday of the previous rotation, or if the last rotation was more than a week ago.

We could also change the number of times a log is rotated before old logs are removed by modifying the rotate directive. We can also add mail <email@emailaddress.com> to email log files when they're removed, so long as the system has a functioning mail transfer agent. You can additionally a log file when it reaches a certain logrotate size, with size 150k rotating if it reaches more than 100 kilobytes.

Finally, if you want rotated logs to maintain their file extension, rather than appending .1 to the end, you can add extension log to the config file.

How to Run Logrotate as a Cronjob

With the basics of Logrotate config files explained, it's worth making sure that Logrotate is running as a cronjob to ensure logs are rotated in line with your config files. As it only rotates logs when it runs, having a daily Logrotate rotation but running the  weekly will create mismatch.

We can run a lograte daily by creating a a script in the /etc/cron.daily folder:

cd /etc/cron.daily/
nano logrotate

You can then add something like this, if it's not already there:

#!/bin/sh
logrotate /etc/logrotate.conf

Press Ctrl + O to save the changes and Ctrl + X to exit nano. You can now modify your Logrotate config  to your heart's content and be assured that it will follow your timing preferences.