14

the logs on /var/log/ (Debian/Ubuntu) are stored as

x.log
x.log.1
x.log.2.gz
...

like kernel logs, syslogs, etc.

I see that as the log info increases, they are stored by splitting into smaller files (rather than keeping all in a single file). I wonder why the second file (x.log.1) is not compressed? Is it something to do with accessing more recent logs easier?

Angs
  • 502
  • 2
  • 7
  • 21

3 Answers3

15

I agree with you, that should only provide an easier access to recent files. Anyway, the actual behaviour is decided via logrotate delaycompress directive, which says:

do not compress the file as you rotate, but compress it next time

The historical reason can be found in the logrotate manual:

Postpone  compression of the previous log file to the next rotation 
cycle.  This has only effect when used in combination  with compress. 
It can be used when some program can not be told to close its logfile and 
thus might continue writing to the  previous log file for some time.
Yuri
  • 458
user1293137
  • 1,732
7

Yes, this is done so that more recent log files are easier to access. The logrotate option delaycompress controls this. From the logrotate manpage:

delaycompress

Postpone compression of the previous log file to the next rotation cycle.  
This only has effect when used in combination with
compress.  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.
jordanm
  • 42,678
  • 5
    These options are used in the files under /etc/logrotate.conf and /etc/logrotate.d/*. – slm Aug 07 '13 at 15:30
  • "easier to access" is a side-effect, not the main reason. The main reason is to avoid unlinking files while programs are still writing to them; anything written to the file after gzip stops reading (and then removes) the original file will be lost when the writer closes the file. – Martin Kealey Jan 10 '23 at 07:35
0

In short, no, it has nothing to do with wanting to make recent logs easier to access.

Rather, daemons will often continue writing to the logfiles after they've been renamed, and sometimes for a long time.

Once a log file gets compressed (which really means writing a new file and deleting the old one) anything subsequently written to the original - now-deleted - file would be lost when the logfile is finally closed.

Sometimes a daemon can get "stuck" and refuse to close its log file. If that happens you might see this:

$ pid=$(pidof your_daemon)
$ ls -l /proc/$pid/fd/* | grep log
l-wx------ 1 root root 123456789 Jan 10 17:54  /proc/1234/fd/6 -> /var/log/your_daemon.log (deleted)
$ ls -lL /proc/$pid/fd/6 /var/log/your_daemon.log
-rw-r----- 0 root root 123456789 Jan 10 17:54  /proc/1234/fd/6
-rw-r----- 1 root root         0 Jan 10 01:04  /var/log/your_daemon.log
$ cmp /proc/$pid/fd/6 <( gunzip < /var/log/your_daemon.log.2.gz )
cmp: EOF on /dev/fd/63
  • /proc/$pid/fd/6 is still open and being written to but its link count is 0 - it has no names in the filesystem;
  • /var/log/your_daemon.log is empty (size 0) because nothing is writing to it;
  • /var/log/your_daemon.2.gz is a compressed copy of the log at the time the compression was done; its content is identical to the open log file, up to the point where it's truncated.

Anything past the truncation will be permanently lost once the open-but-unlinked logfile is closed.

Martin Kealey
  • 560