logrotate compress files after the postrotate script

Question

I have an application generating a really heavy big log file every days (~800MB a day), thus I need to compress them but since the compression takes time, I want that logrotate compress the file after reloading/sending HUP signal to the application.

/var/log/myapp.log {
    rotate 7
    size 500M
    compress
    weekly
    postrotate
        /bin/kill -HUP `cat /var/run/myapp.pid 2>/dev/null` 2>/dev/null || true
    endscript
}

Is it already the case that the compression takes place after the postrotate (which would be counter-intuitive)? If not Can anyone tell me if it's possible to do that without an extra command script (an option or some trick)?

Thanks Thomas

score 53 · Answer 1 · edited Jul 20 '18 at 11:37

53

Adding this info here in case of anyone else that comes across this thread when actually searching for wanting a way to run a script on a file once compression has completed.

As suggested above using postrotate/endscript is no good for that.

Instead you can use lastaction/endscript, which does the job perfectly.

edited Jul 20 '18 at 11:37

Ng Sek Long

4,233
2
31
38

answered Aug 22 '12 at 11:28

Mark

631
1
5
3

You're the man. Saved me at least 30 minutes of googling/reading. – Jim Rubenstein Feb 20 '18 at 21:29
You may want to create a separate question and answer it, you'll gain reputation and improve the quality of this answer thread. – Thomas BDX Mar 31 '20 at 15:30

score 24 · Answer 2 · answered Nov 12 '11 at 01:47

24

The postrotate script always runs before compression even when sharedscripts is in effect. Hasturkun's additional response to the first answer is therefore incorrect. When sharedscripts is in effect the only compression performed before the postrotate is for old uncompressed logs left lying around because of a delaycompress. For the current logs, compression is always performed after running the postrotate script.

answered Nov 12 '11 at 01:47

JW-padded-to-three-chars

241
2
2

I just discovered this for myself. Agreed that @Hasturkun should revise or remove his comment. – mateolargo May 24 '12 at 18:09
2

Had this been a comment, I would have likely responded in less than eight months – Hasturkun Sep 10 '12 at 16:37

score 16 · Accepted Answer · answered Sep 01 '11 at 14:46

16

The postrotate script does run before compression occurs: from the man page for logrotate

The next section of the config files defined how to handle the log file /var/log/messages. The log will go through five weekly rotations before being removed. After the log file has been rotated (but before the old version of the log has been compressed), the command /sbin/killall -HUP syslogd will be executed.

In any case, you can use the delaycompress option to defer compression to the next rotation.

answered Sep 01 '11 at 14:46

Hasturkun

35,395
6
71
104

2

Thanks, I should have read more carefully the man page ... Though this information should also be under the compress option explanation. – Thomas BDX Sep 01 '11 at 15:19
1

Note to all readers, the above comment seems false based on answer below by @jw-padded-to-three-chars, please refer also to the latter. – Thomas BDX Sep 10 '12 at 08:52
1

@Thomas: Comment was based on this quote from the man page `The sharedscripts means that the postrotate script will only be run once (after the old logs have been compressed), not once for each log which is rotated.` It appears to be my misunderstanding of that quote. `postrotate` scripts are always run before compression of the current logs. (the `delaycompress` option is not affected by `sharedscripts` in any way, other than occuring before the `prerotate` scripts are run) – Hasturkun Sep 10 '12 at 16:32
1

I do believe that the man page is the one responsible for the confusion with those examples. It mentions old logs being compressed, when there is no `delaycompress` directive in the section. The reader is left to infer that `sharedscripts` is the directive that influences order of execution between `compress` and `postrotate`. – Michael Ekoka May 05 '14 at 11:30
2

People interested in the order things are done by logrotate will find `logrotate -d` useful - it tells you exactly what's happening. You'll probably want to use `-f` as well. – David Lord Jul 20 '15 at 01:39
3

So what does the manual means then? To me the "after the old logs have been compressed" part seems not just confusing, but wrong. – Paul Tobias May 03 '16 at 07:46
1

Note: if in postrotate section you need move file(s) to any external storage (ftp, smb, s3, etc) - you have to use ```lastaction/endscript``` section – ALex_hha Sep 29 '17 at 08:51

score 2 · Answer 4 · answered Sep 18 '13 at 20:10

@Hasturkun - One cannot add a comment unless their reputation is first above 50.

To make sure of what logrotate will do, either

test your configuration with, -d: debug which tests but does not do anything, and -f: force it to run
or you can execute logrotate with the -v verbose flag

With a configuration that uses a sharedscript for postrotate

$ logrotate -d -f <logrotate.conf file>

Shows the following steps:

rotating pattern: /tmp/log/messages /tmp/log/maillog /tmp/log/cron
...
renaming /tmp/log/messages to /tmp/log/messages.1
renaming /tmp/log/maillog to /tmp/log/maillog.1
renaming /tmp/log/cron to /tmp/log/cron.1
running postrotate script
<kill-hup-script executed here>
compressing log with: /bin/gzip
compressing log with: /bin/gzip
compressing log with: /bin/gzip

Assuming you are referring to my (retracted) comment, IIRC (It's been a while since then) I checked the logrotate source when the error was brought up. It was indeed wrong, the behavior is unaffected. In any case, testing your configuration is probably a good idea. — Hasturkun, Nov 25 '13 at 16:35

logrotate compress files after the postrotate script

4 Answers4