Python 日志旋转后为什么还写旧文件：handler 重载与进程句柄检查

日志轮转之后，旧文件还在持续变大，先别急着把锅甩给 logrotate。Python 进程可能还持有旧的文件描述符，也可能在启动配置时重复添加了多个 FileHandler。判断这类问题最有效的办法，是把“文件名”“handler 重新打开动作”和“进程 fd”放在同一条证据链里梳理排查。

日志旋转后旧文件还能写入，核心是两个常见场景：一是外部切分文件后，Python 原进程持有的旧文件句柄没有被释放，仍在往旧 inode 对应的文件里写；二是日志配置初始化时重复注册了多个指向旧路径的 handler，导致同一日志被多次写入旧文件。

先确认旧文件到底是谁还在写

假设应用写入 /var/log/report-worker/app.log。凌晨轮转后目录里出现了 app.log 和 app.log.1，但过了一会儿 app.log.1 仍然变大。这个现象只能说明有进程持有旧文件，不能直接证明 Python logger 配错。

ls -li /var/log/report-worker/app.log*
lsof -nP | grep '/var/log/report-worker/app.log'

如果 lsof 显示 Python 进程的 fd 仍指向已经改名的 app.log.1，说明进程没有重新打开新文件。若同一个路径出现两个 fd，则要继续查 logger 是否被初始化了两次。

外部轮转要让 handler 感知 inode 变化

外部工具通常负责改名、压缩和创建新文件。普通 FileHandler 只在初始化时打开一次路径，文件名变了，它并不知道目录里已经换了一份文件。此时更适合使用 WatchedFileHandler：

import logging
from logging.handlers import WatchedFileHandler

logger = logging.getLogger("report-worker")
logger.setLevel(logging.INFO)
logger.propagate = False
if not logger.handlers:
    handler = WatchedFileHandler("/var/log/report-worker/app.log", encoding="utf-8")
    handler.setFormatter(logging.Formatter("%(asctime)s %(process)d %(message)s"))
    logger.addHandler(handler)
logger.info("worker ready")

它会在写入前检查文件的设备号和 inode。发现路径对应的文件已被外部轮转替换后，handler 会关闭旧流并重新打开当前路径。这个行为解决的是“外部轮转后仍写旧 inode”，不是“多个 handler 叠加写入”。它主要面向 Unix/Linux 系统，跨平台服务要先确认目标系统的文件变化语义。

应用内轮转和外部轮转只能选一个负责人

如果不希望依赖外部工具，可以让 Python 自己按大小轮转：

from logging.handlers import RotatingFileHandler

handler = RotatingFileHandler("app.log", maxBytes=20 * 1024 * 1024, backupCount=5, encoding="utf-8")

实际项目里不要在每次启动时无条件调用 doRollover()，正常情况下由 handler 根据写入大小触发。若同时配置 logrotate 和 RotatingFileHandler，两套规则可能互相改名：应用以为自己持有当前文件，外部工具却已经把它移走，最终留下难以解释的旧 inode。

重复 handler 会制造轮转失效的假象

模块导入、开发服务器重载、测试重复初始化或 worker fork 后再次配置，都可能多出几个 handler。每条日志被写两次，看起来像轮转后的旧文件异常增长。

def configure_logger():
    logger = logging.getLogger("report-worker")
    logger.setLevel(logging.INFO)
    logger.propagate = False
    if not logger.handlers:
        logger.addHandler(build_handler())
    return logger

logger = configure_logger()
for index, item in enumerate(logger.handlers):
    print(index, type(item).__name__, getattr(item, "baseFilename", None))

如果业务确实需要控制台和文件两个输出，handler 数量为 2 是合理的；关键是每个 handler 的目标和级别要清晰可查。多进程共享一个文件 handler 还会带来轮转竞争，稳定的边界通常是每个进程写标准输出，再由采集器统一收集。

用一条检查链验收修复

1. 记录 app.log 的 inode、大小和修改时间。
2. 执行一次外部轮转，确认新旧文件 inode 不同。
3. 让 Python 进程再写一条带进程号的日志，观察新文件是否出现。
4. 用 lsof 检查旧文件是否仍被持有，并统计 handler 数量。
5. 如果是多进程，分别检查每个进程的 fd，不要只看父进程。

验收标准很具体：新文件继续增长，旧文件大小不再变化；每条业务事件只出现一次；进程重启和轮转各做一次后，handler 数量都没有累加。

常见问题

为什么改名后 FileHandler 还写旧文件？

FileHandler 持有已经打开的文件对象，外部改名不会自动改变它指向的 inode。使用 WatchedFileHandler，或重启进程重新打开文件。

WatchedFileHandler 能解决重复日志吗？

不能。它只处理外部轮转后的文件变化；重复日志要从 handler 数量、propagate 设置和多进程初始化路径排查。

可以同时使用 logrotate 和 RotatingFileHandler 吗？

不建议让两者共同管理同一个文件。选择一个轮转负责人，避免命名竞争和旧 fd 残留。

多进程写一个日志文件安全吗？

不能只根据单进程测试下结论。轮转时多个进程可能同时改名或继续持有旧 fd，生产环境更稳妥的边界通常是每进程输出标准输出，再由外部采集系统统一处理。

把文件名、inode 和 handler 对上号

先用 inode 找到旧文件，再用进程 fd 确认谁还在写，最后回到 logger 初始化代码核对 handler 责任。外部工具轮转就配合 WatchedFileHandler，应用自己轮转就使用一套明确的 rotating handler；把两种策略拆开，问题通常会在一次轮转验收里暴露出来。