When to use delaycompress option in logrotate?

Question

The man page of logrotate says that:

It can be used when some program cannot be told to close its logfile
and  thus  might  continue writing to the previous log file for some
time.

I'm confused by this. If a program cannot be told to close its logfile, it will continue to write forever, not for sometime. If the compression is postponed to next rotation cycle, the program continues to write to that file even after the next rotation cycle. How is postponing solving the problem?

My understanding is that copytruncate should be used when a program cannot be told to close the logfile. I'm aware that some data written to the logfile gets lost when the copy is in progress.

I was looking at the logrotate file for couchdb, and it had both copytruncate and delaycompress options.

/usr/local/couchdb-1.0.1/var/log/couchdb/*.log {
   weekly
   rotate 10
   copytruncate
   delaycompress
   compress
   notifempty
   missingok
}

It looks like there is no point using delaycompress when copytruncate is already there. What am I missing?

score 37 · Accepted Answer · answered Jul 21 '11 at 02:55

37

Your understanding of copytruncate is correct, but the wording in the manpage for delaycompress is a little misleading. More properly, it should say "when some program cannot be told to immediately close it's logfile" -- for instance, if you're using sharedscripts and the script sends a signal to the process using the log when all the log files have been rotated.

answered Jul 21 '11 at 02:55

womble

95,029
29
173
228

1

When I'm using `copytruncate`, there is no need to tell the program to close it's logfile. So is it meaningless to specify `delaycompress` along with `copytruncate`? – Anand Chitipothu Jul 21 '11 at 06:31
6

Never use `copytruncate` unless you *absolutely* have to, because it loses log entries. You can use both options if you want the other feature that `delaycompress` provides -- the ability to read the previous logfile without needing to decompress it first. – womble Jul 21 '11 at 07:08
Is there any option other than `copytruncate` if I can't tell my program to reload? – Anand Chitipothu Jul 25 '11 at 04:33
5

No. It's why you should use software that doesn't suck, and which will accept a signal to say "reload your logs". – womble Jul 25 '11 at 05:26

score 4 · Answer 2 · edited Apr 18 '18 at 16:26

4

We use:

daily
delaycompress
nodateext

This creates fixed copy of the apache access_log access_log.1 so that we can then run our Stats package as a script at the end of the day.

The following day logrotate compresses the file creating access_log.2.zip

edited Apr 18 '18 at 16:26

Giacomo1968

3,522
25
38

answered Jan 11 '18 at 01:37

Edwardg

41
1

score 3 · Answer 3 · edited Nov 22 '12 at 09:35

3

Not sure if I completely understand your question, but if you're asking what I think...I use this:

postrotate
          killall -HUP syslog-ng
  endscript

That's a nice (or at least a) way to kill the log and move to the next. For "programs" that suck, such as Cisco's ASA platform that log tons of data per second, it works.

edited Nov 22 '12 at 09:35

HopelessN00b

53,385
32
133
208

answered Mar 15 '12 at 04:19

Warren

31
1

score 0 · Answer 4 · answered Aug 12 '21 at 10:34

The reason for this is when software performs its own rotation. This is usually done by copying the current log to a newly created file, then truncating the original. This can take some time and logrotate don't have any mechanism to signal back that a file is ready to be compressed.

Logrotate can be used only to compress and maintain archives rather than performing the actual rotation.

When to use delaycompress option in logrotate?

4 Answers4