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

【问题标题】：How to prevent logrotate from producing unwanted ".backup" files如何防止 logrotate 产生不需要的“.backup”文件
【发布时间】：2019-01-21 23:18:54
【问题描述】：

我在 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

但是，它也会偶尔产生一堆不需要的“备份”，随着时间的推移导致磁盘使用失控 - 我们在磁盘空间有限的虚拟机上运行：

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

这完全违背了我最初通过旋转和压缩有限数量的日志来限制磁盘使用量的初衷。

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

我无法找到有关此事的文档。目前我有一个 crontab 设置，它会定期删除这些文件，但这似乎不是“正确”的做事方式。

【问题讨论】：

您是否还有其他一些可能与某些相同文件匹配的 logrotate 设置？使用dateext 指令或类似指令？
@BenjaminW。我没有看到与该目录匹配的其他 logrotate 规则（我检查了 /etc/logrotate.d 中的每个文件），并且对 dateext 进行了 grep，但没有运气。
我唯一能想到的其他地方是/etc/logrotate.conf。
@BenjaminW。也没有引用 /etc/logrotate.conf 中的 dateext 或 /opt/dcm4chee。系统中有另一个日志文件正在发生同样的事情。它们来自不同的进程。但是，与我使用 logrotate 管理的其他内容相比，它们的共同点是它们的写入频率很高（每秒几行）。不确定这是否是一个原因......
可能是其他东西在旋转它们，但我不确定是什么。也许您可以在系统日志中看到一些内容？

标签： ubuntu logrotate

【解决方案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 来临时修复它，它似乎解决了这个问题但必须冒着丢失一些日志的风险。

希望有更好的解决方案~

【讨论】：

有趣的提示——在我的情况下，copytruncate 似乎不能解决问题，我会再看一下，虽然我有时间，有一段时间没有考虑这个问题，我已经解决了创建一个 cron 作业，每晚在这些文件超过 x 天时删除它们。
对我来说，这是因为我有两个 logrotate 实例正在运行。一个在 cron 中，另一个在 cron.d 中；两者将同时运行，导致文件在第二个运行时被锁定，从而创建 .backup 文件。
我的问题在于 xz 选项的compressoptions -9 --threads=0。当内存不足时，logrotate 使用 xz 运行压缩并退出并出现错误 /usr/bin/xz: (stdin): Cannot allocate memory 并留下 *.backup 文件，每次运行失败。删除--threads=0 用于内存较少的一种线程模式。修改线compressoptions -9.
如果这会导致问题，删除create 不是更有意义吗？

【解决方案2】：

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

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

【讨论】：

我也是这样。我花了几天时间试图找出问题所在，但没有意识到两个 cron 运行在哪里。一个在crontab -l，另一个在/etc/cron.daily/logrotate