☰

为什么 /var/log 上的第二个日志文件未压缩

tag-icon • tag-icon logs
为什么 /var/log 上的第二个日志文件未压缩

(Debian/Ubuntu)上的日志/var/log/存储为

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

如内核日志、系统日志等。

我发现随着日志信息的增加，它们通过分割成更小的文件来存储（而不是将所有内容保存在一个文件中）。我想知道为什么第二个文件（x.log.1）没有被压缩？这是否与更轻松地访问最新日志有关？

答案1

我同意你的观点，这只会提供对最近文件的更轻松的访问。无论如何，实际行为是通过 logrotatedelaycompress指令决定的，该指令表示：

旋转时不压缩文件，但下次压缩它

历史原因可以在logrotate手册中找到：

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.

答案2

是的，这样做是为了更容易访问最新的日志文件。 logrotate 选项delaycompress控制这一点。来自 logrotate 联机帮助页：

延迟压缩

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.

答案3

简而言之，不，它与想要使最近的日志更易于访问无关。

相反，守护进程通常会在重命名后继续写入日志文件，有时会持续很长时间。

一旦日志文件被压缩（这实际上意味着写入新文件并删除旧文件），当日志文件最终关闭时，随后写入原始（现已删除）文件的任何内容都将丢失。

有时，守护进程可能会“卡住”并拒绝关闭其日志文件。如果发生这种情况，您可能会看到以下内容：

$ 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仍然打开并正在写入，但其链接计数为0- 它有不文件系统中的名称；
  • /var/log/your_daemon.log是空的（大小0）因为没有任何东西写入它；
  • /var/log/your_daemon.2.gz是压缩完成时日志的压缩副本；其内容与打开的日志文件相同，直到被截断为止。

一旦关闭打开但未链接的日志文件，任何超过截断的内容都将永久丢失。

相关内容