我继承了一个同时使用 logcheck 和 logrotate 的系统。我遇到的问题是 logrotate 发送了一封令人讨厌的电子邮件，内容大致如下：
*** WARNING ***: Log file (X) is smaller than last time checked!
每当 logrotate 旋转监视的文件时。这些工具似乎被设计成可以很好地协同工作，所以我很好奇如何实现它。
这看起来很简单，如果我问了一个在帮助文件中的愚蠢问题，我深表歉意。
Ubuntu 18.04、logcheck 1.3.17、logrotate 3.11.0 - 版权所有 (C) 1995-2001 Red Hat, Inc.
额外的问题是，由于'copytruncate'是用于管理文件轮换的方法：
需要轮换日志的服务是 Django / Apache 应用程序。服务本身（和文件）实际上不能因为轮换过程而停止，因为它是需要正常运行时间的 Web 服务器。您能为我指明开始干净地轮换这些文件的正确方向吗？此过程已将 logrotate 和 logcheck 一起干净地运行，但我们最近升级到了 Python 3.1，这可能是导致潜在问题的原因。
第二条补充：这个问题可能是由于开发人员对某些相互冲突的文件大小限制（Django 将日志限制为 4M，而 logrotate 则以 5M 为单位旋转）感到恼火，并自行截断日志而引起的。了解 logrotate + logcheck 拥有良好的记录非常有帮助。
答案1
我在 Debian 系统上使用logcheck+logrotate已有 20 年，目前在约 60 台 Debian 版本 8、9 和 10 服务器上使用它们，并且我已经绝不看到了来自 的消息logcheck。所以我做了一些调查。
该消息实际上并非来自logcheck其本身，而是来自logtail2（或最初是logtail），它位于logcheck作为依赖项引入的子包中。根据logtail包描述，两个版本之间的主要区别在于它logtail2更善于处理已轮换的文件。鉴于此，我首先检查logtail您logcheck正在使用哪个：
$ grep logtail /usr/sbin/logcheck
LOGTAIL="/usr/sbin/logtail2"
|| error "Could not run logtail or save output"
验证第一行是否LOGTAIL设置为logtail2，而不是logtail。
假设它正在使用logtail2（应该如此），只有当文件缩小时才会发出“日志文件较小”警告和换句话说，如果文件已被就地重写，则 inode 编号保持不变。有时这样做是为了处理那些不够智能的服务，这些服务无法根据需要重新创建日志文件，因此日志会通过复制日志然后将大小重置为 0 来进行轮换，而不是重命名并创建新文件。因为这是一种不寻常的（而且相当不靠谱，更不用说有风险了，因为它会创建竞争条件，从而导致日志消息丢失）处理日志轮换的方法，我猜你只有少量的日志文件会出现此警告。
解决此问题的最佳方法是修复相关日志的轮换设置，以便以“正常”方式处理它们，而不是覆盖旧日志。为此，grep您需要为使用该copytruncate选项的任何日志制定 logrotate 规则，然后确定需要做什么才能让这些服务允许轮换而不使用copytruncate- 实现此目的的强力方法是在prerotate脚本中停止服务并在 中重新启动它postrotate，但通常有更好的方法，例如向它发送特定信号以告诉它重新打开其日志文件。（如果您找不到任何提及 的内容copytruncate，也可以在轮换脚本中手动实现该技术，您必须手动查找而不是使用grep。）
如果那不是一个选项，您可能能够在logcheck规则目录中创建忽略规则，告诉它忽略那些警告行，但这取决于它们是否被处理为标准异常日志条目或者它们是否绕过忽略系统。