fail2ban报告/var/log/auth.log文件已移除的原因求助

我每天都会查看Logwatch生成的日志，最近发现每次执行apt upgrade并重启系统后，/var/log/auth.log文件都会被清空。昨天升级重启后，Fail2ban的Logwatch报告里出现了相关记录，具体内容如下：

--------------------- fail2ban-messages Begin ------------------------

Informational Messages:
banTime: 600: 1 Time(s)
encoding: UTF-8: 1 Time(s)
findtime: 600: 1 Time(s)
maxLines: 1: 1 Time(s)
maxRetry: 5: 1 Time(s)
--------------------------------------------------: 1 Time(s)
Connection to database closed.: 1 Time(s)
Observer start...: 1 Time(s)
Observer stop ... try to end queue 5 seconds: 1 Time(s)
Observer stopped, 0 events remaining.: 1 Time(s)
Removed logfile: '/var/log/auth.log': 1 Time(s)
Shutdown in progress...: 1 Time(s)
Starting Fail2ban v0.11.2: 1 Time(s)

Notices:
[sshd] Flush ticket(s) with iptables-multiport: 1 Time(s)

---------------------- fail2ban-messages End ------------------------

结合你的操作场景和日志记录，我整理了几个大概率的原因：

• 日志轮转工具的自动操作：系统默认用logrotate管理日志文件，当auth.log达到轮转条件（大小/时间）时，会被归档压缩并创建新的空日志文件。如果升级过程中logrotate的配置被更新，或者轮转触发时机刚好和重启重叠，Fail2ban的监控进程会把“旧文件被替换”识别为“文件被移除”。
• 升级关联服务的重启：apt upgrade如果涉及到sshd、rsyslog这类和auth.log相关的服务，升级后服务重启会触发日志文件的重新创建，旧文件被替换时就会被Fail2ban记录下来。
• Fail2ban自身的监控逻辑：Fail2ban通过监控文件inode来追踪日志变化，当日志文件被替换（比如轮转后），它会判定原文件被移除，随后自动切换到监控新文件，这条记录其实是正常的兼容处理日志。

如果auth.log只是被清空而非彻底消失，那大概率是logrotate的copytruncate模式导致的——这种模式会先复制日志内容到归档文件，再清空原文件，虽然inode不变，但服务重启时的文件重建操作还是会被Fail2ban捕捉到并记录。

你可以先检查/etc/logrotate.d/rsyslog（管理auth.log的默认配置文件）里的设置，看看是否启用了copytruncate；也可以手动执行一次logrotate -f /etc/logrotate.d/rsyslog，观察是否会重现同样的日志记录，以此确认问题根源。

备注：内容来源于stack exchange，提问作者chmike