2

I had a logrotate configuration file set up for a log (let's call it Log1). It is working fine and the log is rotating everyday as expected.

Yesterday I cloned this set up and modified it for three more log files Log2, Log3 and Log4. These log files already exist on disk, and are being actively written to.

However, when checked today, the three log files did not rotate at all. I was expecting them to rotate along with the first log file Log1. But only Log1 was rotated, and the rest (Log2 to Log4) weren't touched at all.

If I place new configuration files for logrotate, do I have to run a command to "activate" them so logrotate will start rotating the log files? I thought since it's a cron job running at 4 am everyday, it will automatically pick up the new files and rotate files. Is there some sort of manual activation needed?

What's strange is that the /var/lib/logrotate.status file seems to show (with today's date) that all four log files were looked at by logrotate. So, why did logrotate skip the three new log files that obviously need rotating?


Configuration file:

/path/to/Log1.log {
    compress
    compresscmd /usr/bin/bzip2
    compressext .bz2
    compressoptions -9
    copytruncate
    daily
    dateext
    delaycompress
    extension .log
    notifempty
    missingok
    nomail
    olddir Log1
    rotate 100
    maxage 60
}

There shouldn't be anything wrong with the configuration file, since it works fine for Log1. The olddir directory is already created for all the logs.

When running logrotate -d (debug mode), it says log does not need rotating for all four logs. I understand this is correct for Log1 since it's already rotated, but what about the others?

Does it have anything to do with after 1 days? Does logrotate first mark the new file's date in logrotate.status file, then only rotate when one day has elapsed since the last mark? How is the status file used by logrotate?

6
  • Does logrotate -d (debug mode) show anything enlightening? Maybe there's one more place you need to change the filename in the config file (I'm sure this not only happens to me?). logrotate runs with high privileges, so there shouldn't be permissions issues, like being unable to read/create the files, but double-checking can't hurt. Commented Feb 27, 2014 at 7:32
  • It says log does not need rotating for all four logs. I understand this is correct for Log1 since it's already rotated, but what about the others? Also, all owners, groups, rights are exactly the same for all four log files and related files/directories.
    – ADTC
    Commented Feb 27, 2014 at 7:35
  • 1
    Please include your logrotate config file for one of the failed rotations in the question.
    – Jenny D
    Commented Feb 27, 2014 at 7:39
  • Does it have anything to do with after 1 days? Does logrotate first mark the new file date's in logrotate.status file, then only rotate when one day has elapsed since the last mark? How is the status file used by logrotate?
    – ADTC
    Commented Feb 27, 2014 at 7:41
  • Do you have a minsize setting in the logrotate configuration? If the new files haven't reached that size they won't be rotated.
    – Barmar
    Commented Feb 27, 2014 at 7:52

1 Answer 1

1

It appears that logrotate works using the logrotate.status file. In this status file, the log's modified date is marked down. The rotation only kicks in once the modified date of the log file changes from the marked date by a given delta (usually 1 day).

The status file is used by logrotate to avoid rotating a log file multiple times before the delta time has elapsed. Although I would reckon there's no harm in starting to rotate a file that is not yet marked in the status file and simply marking it fresh afterwards, I do not know why logrotate did not adopt this strategy.

If anyone provides a more substantial and detailed answer describing the above and explaining the reasons for it, I will accept your answer.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .