Logrotate成功，原始文件恢复为原始大小

是否有人在使用logrotate之前遇到任何问题，然后才导致日志文件旋转，然后恢复到原来的大小？这是我的发现：

Logrotate脚本：

/var/log/mylogfile.log {
    旋转7
    日常
    压缩
    olddir / log_archives
    Missingok
    无可辩驳的
    复制截断
}

Logrotate的详细输出：

将/var/log/mylogfile.log复制到/log_archives/mylogfile.log.1
截断/var/log/mylogfile.log
使用以下命令压缩日志：/ bin / gzip
删除旧日志/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 1月11日17:32 /var/log/mylogfile.log

RHEL版本：

[root @ server〜]＃cat / etc / redhat-release 
红帽企业Linux ES版本4（Nahant更新4）

对数旋转版本：

[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 of=largefile.bin seek=3432343264 bs=1在几毫秒内生成超过3GB的文件）。

如果您ls -ls在日志文件被截断并再次突然增长后对其运行，则它现在应该在行的开头报告一个数字，该数字代表实际大小（以磁盘上占用的块为单位），可能约为数量级小于刚报告的大小ls -l。

我非常相信Kjetil做到了。德鲁，您可能还不相信他的解释，但我敦促您仔细阅读他的讲话。

如果您接受它，那么解决方法是在旋转日志时停止并重新启动应用程序，或者使用apache的“ rotatelogs”之类的工具，在该工具中，通过管道将日志输出馈送到该工具，并且该工具负责经常轮换日志文件。例如，我的一个apache实例记录有

ErrorLog "|/usr/sbin/rotatelogs /www/logs/error_log 604800"

这会导致很多名称如下的日志文件

-rw-r--r--    1 root     root         4078 Dec 21 01:04 error_log.1292457600
-rw-r--r--    1 root     root         4472 Dec 29 08:41 error_log.1293062400
-rw-r--r--    1 root     root        78630 Jan  4 12:57 error_log.1293667200
-rw-r--r--    1 root     root        15753 Jan 12 01:10 error_log.1294272000

出现而无需重新启动apache；之后，我可以手动压缩它们。请注意，每周的轮换操作是每604800秒，这是传递给的参数rotatelogs。

如果您无法停止并重新启动该应用程序，并且无法通过管道登录，那么我认为您遇到了一个实际问题。也许其他人会提出建议。

如果您可以发送整个logrotate，那就太好了。

为什么尝试使用kill -HUP？（经典重载不会重新启动）方法。

另外...请检查lsof 谁正在访问文件。

只需使用“ >>”表示附加，而不使用“>”，后者表示从写入此文件的脚本中创建。我遇到了完全相同的问题，并在脚本中使用append修复了该问题。

SomeScript.sh >> output.txt

希望更清楚。