有没有人有任何问题与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的文件).
如果你的日志文件在被截断并且再次突然增长后运行ls -ls,它现在应该在行的开头报告一个数字,表示实际大小(在磁盘上占用的块),这可能是比ls -l报告的大小小几个数量级.
