有没有人有任何问题与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报告的大小小几个数量级.
