Question

我在ubuntu 16.04上有一个logrotate配置，它打算每天将我的日志旋转到gz。配置如下：

/opt/dcm4chee/server/default/log/*.log {
    daily
    missingok
    rotate 5
    compress
    notifempty
    create 0640 dcm4chee dcm4chee
    sharedscripts
    copytruncate
}

它可以正确生成压缩后的日志：

server.log.1.gz
...
server.log.5.gz

但是，它还会偶尔散发出一堆不必要的“备份”，从而导致磁盘使用率失控-我们在有限的磁盘空间VM上进行操作：

server.log.1-2018063006.backup
...
server.log.1-2018081406.backup

这完全违反了我最初限制旋转磁盘并压缩有限数量的日志的最初目的。

如何完全停止logrotate生成这些“备份”？如果这意味着丢失几行日志记录，那就这样吧。

我找不到有关此事的文档。目前，我有一个crontab设置，该设置可以定期删除这些文件，但是这似乎不是“正确”的处理方式。

Answer 1

遇到相同的问题，发现这是由重复的日志文件引起的。

就我而言，我正在对一些nginx日志进行日志旋转，并且通过使用create方法，有时会发生这种情况，当它尝试创建新日志文件时，nginx仍然会产生新日志并导致以下错误：

error: destination /[example path]/access.log already exists, renaming to /[example path]/access.log-2018122810.backup

，因此它会不断生成大量的“ .backup”文件并占用我的磁盘空间。

经过一些研究，我只是找不到杀死所有Nginx进程的好方法，因此我通过在logrotate.d配置中添加copytruncate来临时修复它，看来可以解决此问题，但必须冒险，您可能会丢失一些日志。

希望有更好的解决方案〜

Answer 2

当 logrotate 的两个实例在同一组日志文件上同时运行时，就会发生这种情况。

例如 - 当一个实例作为您每天运行的常规 cron.d 的一部分运行而另一个实例作为您的 cron 作业的一部分运行时，就会发生这种情况

如何防止logrotate产生不需要的“ .backup”文件

2 个答案: