概述

有没有人有任何问题与logrotate之前导致日志文件旋转,然后回到原来的相同大小？这是我的发现： Logrotate脚本： /var/log/mylogfile.log { rotate 7 daily compress olddir /log_archives missingok notifempty copytruncate } L

有没有人有任何问题与logrotate之前导致日志文件旋转,然后回到原来的相同大小？这是我的发现：

Logrotate脚本：

/var/log/mylogfile.log {
    rotate 7
    daily
    compress
    olddir /log_archives
    missingok
    notifempty
    copytruncate
}

Logrotate的详细输出：

copying /var/log/mylogfile.log to /log_archives/mylogfile.log.1
truncaTing /var/log/mylogfile.log
compressing log with: /bin/gzip
removing old log /log_archives/mylogfile.log.8.gz

截断发生后的日志文件

[root@server ~]# ls -lh /var/log/mylogfile.log
-rw-rw-r--  1 part1 part1 0 Jan 11 17:32 /var/log/mylogfile.log

字面上的秒数：

[root@server ~]# ls -lh /var/log/mylogfile.log
-rw-rw-r--  1 part1 part1 3.5G Jan 11 17:32 /var/log/mylogfile.log

RHel版本：

[root@server ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux ES release 4 (Nahant update 4)

Logrotate版本：

[root@DAA21529WWW370 ~]# rpm -qa | grep logrotate
logrotate-3.7.1-10.RHel4

几点说明：

>服务无法动态重启,这就是我使用COpytruncate的原因
>根据每天晚上都有日志文件的olddir目录,日志每晚都在旋转.

解决方法

这可能是因为即使您截断文件,写入文件的进程也将继续以最后的偏移量写入.所以正在发生的事情是logrotate截断文件,大小为零,进程再次写入文件,继续它停止的偏移量,你现在有一个NULL字节的文件,直到你截断它加上新的写入日志的条目.

截断突然增长后的od -c,产生的输出顺序如下：

0000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
33255657600  \0   C   K   B   -   s   e   r   v   e   r       [   h   t   t
33255657620 <more log output>

这说的是从偏移0到33255657600你的文件由空字节组成,然后是一些清晰的数据.进入此状态并不需要花费相同的时间来实际编写所有这些空字节. ext {2,3,4}文件系统支持称为稀疏文件的东西,所以如果你寻找一个不包含任何内容的文件区域,那么该区域将被假定为包含空字节而不占用空间在磁盘上.那些空字节实际上不会写入,只是假设在那里,因此到0到3.5GB所需的时间不需要花费很多时间. (您可以通过执行dd if = ${HOME} / .bashrc = largefile.bin seek = 3432343264 bs = 1来测试所花费的时间,这应该会在几毫秒内生成超过3GB的文件).