linux – Logrotate成功,原始文件恢复原始大小
有没有人有任何问题与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的原因 解决方法
这可能是因为即使您截断文件,写入文件的进程也将继续以最后的偏移量写入.所以正在发生的事情是logrotate截断文件,大小为零,进程再次写入文件,继续它停止的偏移量,你现在有一个NULL字节的文件,直到你截断它加上新的写入日志的条目.
截断突然增长后的od -c,产生的输出顺序如下: 0000000 * 33255657600 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报告的大小小几个数量级. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |