Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Someone just asked me 'how long should we keep logs for our application', and my answer was 'until the disk is full' as there's no reason to throw them away other than running out of space.

However, standard logrotate wants us to specify a specific period + number of rotations. Is there something similar that would let us say "rotate daily, and keep as much history as you like until there is only 5% space free"?

The platform is Redhat Linux.

share|improve this question
Keeping logs until disk is full can be applied on physical environments, but as we mostly move to virtual servers and cloud, filesystem size should be as small as possible to lower costs. In this case, you cannot avoid defining a retention policy. – jfgagne Mar 24 '12 at 11:10

You can perhaps use firstaction or lastaction directives to call a shell script that tests for disk free space, and then run a delete on the oldest files.

          The lines between firstaction and endscript (both of which must appear on lines by themselves) are
          executed (using /bin/sh) once before all log files that match the wildcarded pattern are  rotated,
          before  prerotate  script  is  run  and  only if at least one log will actually be rotated.  These
          directives may only appear inside a log file definition. Whole pattern is passed to the script  as
          first  argument.  If  the script exits with error, no further processing is done. See also lastac-


Here's a Stackoverflow post on the type of script you can run:

share|improve this answer

logrotate itself has no such option. You can add a cron script that find the oldest log to remove whenever the free space falls below your criteria. You can do some other validation as well. However, getting disk too full all the time is not a good idea because the system will not be able to create large temporary files and could cause application failures.

share|improve this answer
If you have everything on one filesystem, it may not be a good idea. However, my logs are on their own filesystem, in order to avoid getting in the way of anything else. – kdt Mar 23 '12 at 17:16
ah ok, if they have their only fs, it makes things simple to have a script to do the cleaning, dh /fs and use awk or cut to extract % used, and based on that figure, you can kick off a find with exec rm. i often do not write a script and just put a one-liner in the crontab itself. – johnshen64 Mar 23 '12 at 17:31

I just wanted to point out there are cases where you don't want your logs to fill all available disk space. I have dealt with several hosts with thin provisioned /var directories and keeping the logs to a certain size was crucial. We used a cronies job in conjunction with logrorate to keep the size down. Something similar could be used in your environment, although a central log server like splunk or syslog-ng would probably be a better option.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.