1

Apache2 on an Ubuntu 16.04 box was showing issues on the websites it's hosting. It was at 100% capacity. Looking further with du, The majority of the ~100gb hard drive was filled by two files in /var/lib/logrotate/.

logrotate has files in there which are called /var/lib/logrotate/status and /var/lib/logrotate/status.clean and taking up a lot of space... 30gb and 60gb.

I'm aware that logrotate is used to regularly clear log files but it seems that it doesn't clear it's own 'log' files by default. I resolved the disk space issue by deleting the two files in there rm -rf /var/lib/logrotate/*.

(/var/lib/logrotate/status has repopulated with new logs from rotate processes throughout the day)

Is this something that is going to keep happening if logrotate doesn't rotate it's own logs?

Angelo
  • 111
  • 1
  • 4
  • The logrotate status file is not a log file. It stores the time when a file has last been rotated. If you remove or truncate the file, logrotate will consider every file as new, and therefore not rotate it, i.e. logrotate will stop working. – Bachsau Aug 20 '20 at 19:27

2 Answers2

1

Deleting or rotating the logrotate.status file is only a band-aid. You need to take a step backward and ask the question, "why is the logrotate.status file that large?"

I would tail -n 500 that status file and see what files are listed in there. I think there's a real strong possibility that your logrotate config file(s) are rotating stuff you never intended to be rotated.

user3629081
  • 325
  • 1
  • 8
-1

You can setup a cron job to either clean up or rotate/truncate the logrotate.status file on a routine basis. I'd recommend a weekly one if your server volume is moderate, daily if extremely heavy traffic.

To setup a weekly cron job that resets the logrotate.status file:

  1. open cron crontab -e
  2. add the entry * * * * 1 echo > /var/lib/logrotate.status

To setup rotation of the file every week: Create a script (make sure it's executable by the cron user) and run a weekly cron to call the it.

Example Script:

#!/bin/bash
/bin/mv /var/lib/logrotate.status.3 /var/lib/logrotate.status.4
/bin/mv /var/lib/logrotate.status.2 /var/lib/logrotate.status.3
/bin/mv /var/lib/logrotate.status.1 /var/lib/logrotate.status.2
/bin/mv /var/lib/logrotate.status /var/lib/logrotate.status.1

To set the script's file permissions:

chmod u+x [script-filename]

Cron task format:

* * * * 1 /full/path/to/your/script
Anson W Han
  • 404
  • 2
  • 6
  • This line will cause issues with all logrotate processes... `echo > /var/lib/logrotate.status`. This answer is very similar with what is found [here](https://www.experts-exchange.com/questions/25334099/How-to-clean-var-lib-logrotate-status.html) however it is not a solution. (The echo command will leave a blank line in the file thus corrupting the file and stopping logs from rotating) – Angelo Dec 19 '17 at 14:29
  • 1
    This does not seem to be a solution. One should look into why the files are so huge, possibly there are wrong patterns in the configuration. – Richlv Sep 12 '18 at 06:17
  • Not that I would recommend to do this, but if you just want to avoid the insert of a line break, you could use `echo -n /var/lib/logrotate.status`. If you want it to use a different INode, you might want to `rm /var/lib/logrotate.status && touch /var/lib/logrotate.status`. This will delete the old file and create a new (empty) one – boppy Nov 22 '19 at 13:10
  • The logrotate status file is not a log file. It stores the time when a file has last been rotated. If you remove or truncate the file, logrotate will consider every file as new, and therefore not rotate it, i.e. logrotate will stop working. – Bachsau Aug 20 '20 at 19:27