How To Install And Setup Logrotate On Linux

Mar 9, 2026 · 10 mins read

How To Install And Setup Logrotate On Linux

In the video below, we show how to install and setup logrotate

In IT, logs bring a lot of benefits to your computer

If something goes wrong, check the logs, they’ll probably tell you what caused the problem

If someone is trying to hack into your computer, check the logs, they’ll probably show you the signs

Although if you aren’t monitoring disk space, log files that keep growing can of course crash your computer…apparently

Thankfully you can install logrotate on Linux computers to well, rotate your log files and reduce the chances of a computer running out of disk space

Oddly enough logs rarely actually get read, because you’ve got better things to do

But hey, the more automation you can add the better

Useful links:
https://linux.die.net/man/8/logrotate
https://manpages.debian.org/stretch/logrotate/logrotate.8.en.html

Installation:
The first thing to do is to install lograte, although we’ll do this as root for consistency

su -

For Alpine we’d do this

apk update
apk add busybox logrotate

For Debian we’d do this

apt update
apt install cron logrotate

Bear in mind, there’s a major reliance on cron and we need to make sure that’s installed as well

It might be missing in minimal installs and may not be pulled in as a dependency

And in the case of Alpine, we’ll get crond as part of the busybox package

In any case, fortunately the installation sets up a lot of the automation for us, making life a lot simpler

The first thing we’ll look at is the global configuration file, in this case from a computer running Alpine

cat /etc/logrotate.conf

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# exclude alpine files
tabooext + .apk-new

# uncomment this if you want your log files compressed
compress

# apk packages drop log rotation information into this directory
include /etc/logrotate.d

# system-specific logs may be also be configured here.

So by default, this is saying logs should be rotated weekly and 4 log files should be kept before file deletion begins

It also uses a create method of rotation where it renames the existing log file, then it creates a new and empty file in it’s place

And then we’ve got a setting to say that when a file is renamed it should be given the date as its extension

Interestingly, that setting is commented out for Debian

For Alpine here, we also find certain files are excluded

To save extra space, when a backup log file is created it will also be compressed, and text files are very compressable

But, that too is commented out for Debian

Bear in mind though, these default settings we’re seeing, may not always be honoured as I’ll explain later

But in any case, this config file alone isn’t enough

As you’ll see there’s an extra line at the end to include files in /etc/logrotate.d

In other words, logrotate is looking for instruction files or rules to tell it what log files to rotate along with potentially more specific instructions on how rotation should be done

Rule Files:
Now although there is a main configuration file supplied with logrotate, as I’ve pointed out, there has to be a more specific rule file for this to do anything

At the very least, logrotate needs to know which log file(s) to work with

Now if you’ve already got packages installed, what I’ve found is logrotate may create files to cover these

ls -l /etc/logrotate.d

But if you install anything after you’ve installed logrotate or create your own application or script then you’ll likely need to create your own rule file for that

As an example, here’s one I’ve setup for a script I run to auto update the Alpine OS

nano /etc/logrotate.d/apk_upgrade

/var/log/apk-upgrade.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root root
}

Now the name of the rule file isn’t important to logrotate, but it makes sense to us if it has meaning and in this example it references the name of a script

The first thing this file does is to identify the log file these instructions apply to

Now, you can specify a single log file, multiple files and you can even use wildcards

So if you want the same treatment for multiple log files, you can consolidate this into one rule file

But in this example, we’re declaring instructions for the log file /var/log/apk-upgrade.log that the OS update sends logs to

Now, we already have some default or global settings, but here we can add others and/or override the default settings

I do suggest checking out the website though for all the possible instructions as there are so many and the logs for each package may need different treatment

But in this example, I want the logs rotated each day (daily) and to keep 7 of them before older files are deleted (rotate 7)

I want older log files to be compressed (compress) but not the most recent (delaycompress); This makes it easier for me to check the logs of the previous day

If the log file is missing, that’s OK, I want logrotate to continue on and rotate others (missingok)

Now if the current log file is empty, we don’t want to rotate it (notifempty)

Finally, we set the permissions for the new backup files so they’ll be accessible to us, or at least root

Bear in mind, you can actually have multiple rules in a rule file, although I’m created rule files for each application

Now what I found surprising is I haven’t specified an option here of nodateext and yet when a log file is renamed, it doesn’t get a date extension, instead it gets a number

If we look in the main config file there is a setting of dateext

So even though I didn’t override that setting, what I’ve found with Alpine is that this default setting seems to get ignored

Now that doesn’t matter to me, because the files have a date stamp, but it’s something to bear in mind

And if that’s important to you, and you find that’s happening to you, then add dateext in your rules

In any case, when logrotate first uses this rule, it will rename apk-upgrade.log to apk-upgrade.log.1 and then it will create a new, empty file called apk-upgrade.log

The next time it runs, it will rename and compress apk-upgrade.log.1 so we get a file called apk-upgrade.log.2.gz and so on

So rather than having a single file, that grows and grows, this log will be rotated when we want

Or will it?

Alpine Scheduling:
When it comes to Alpine, there may be nothing else that you need to do if you want log rotations every day or longer

That’s because if you check the /etc/periodic/ folder you’ll see folders for
15min
daily
hourly
monthly
weekly

Check /etc/periodic/daily and you’ll see a file called logrotate

ls -l /etc/periodic/daily

In other words, cron has already been given instructions to run logrotate every day so there’s nothing else to do for the example I’ve given

Now if you need to rotate logs more frequently you could move that file to the hourly folder for instance

But, before you do that check the file permissions before and after

Permissions should be retained if you use the mv command, but there are situations where they aren’t

Now this won’t make any difference if the rules for a log say to rotate it every day, it just means lograte is now checking more frequently

So if a log file needs rotating say every hour, and you’ve set the rule file to do that, well now that will happen because logrotate will be running every hour

TIP: Once logrotate is run, you can check the status

For Alpine check this file

cat /var/lib/logrotate.status

Here it records when a log file was last rotated, and each time logrotate runs, it will actually check this to decide if a log needs rotating

So you should really leave this log file alone, as logrotate heavily relies upon it

But if for some reason you need to reset things, you can delete the file

Then logrotate has no reference as to when a log was last rotated and so it will start from scratch

Debian Scheduling:
For Debian, scheduling is quite different and there’s still a transition going on it seems

For one thing, you’ll find a logrotate file in /etc/cron.daily

That suggests that by default, logs will be rotated daily by cron

But actually, when you check that file, it defers to systemd if it’s running, and it is

cat /etc/cron.daily/logrotate

To see what systemd is up to then we’ll run this command

systemctl list-timers logrotate.timer

It shows you not only when logrotate will next run, but also when it last ran

In any case, we know that by default your logs will be rotated daily, just by systemd not cron

So what if you want more frequent rotation?

Well it’s best to update systemd in that case

First we’ll check the existing timer settings with this command

systemctl cat logrotate.timer

To change this timer we’ll run this command

systemctl edit logrotate.timer

The first time you do this, you’ll see everything is commented out and you’re advised to put your own settings between these two lines

### Anything between here and the comment below will become the new contents of the file

### Lines below this comment will be discarded

And quite helpfully it does show you the default settings further down

Now to change this to an hourly timer for instance, we can add these settings between those two lines

[Timer]
OnCalendar=
OnCalendar=hourly

NOTE: We can’t simply change the timer, we have tell systemd to reset it first, by placing this line in front
OnCalendar=

What this change does is to override the timer, but leave the other settings as is

Now if we check the timer settings again, we’ll see the default settings plus our override

systemctl cat logrotate.timer

And we can check it’s doing its work by running this command

systemctl list-timers logrotate.timer

What you should now see is that logrotate will be run much sooner

But as with Alpine, this just means lograte is now checking more frequently. You still need to update your rules if you want more frequent log rotation

Likewise, you can check the logs here