日志轮转后服务仍写旧文件，文件描述符发生了什么

日志轮转完成后，目录里已经出现了新的 app.log，但服务的写入量仍出现在 app.log.1，这通常不是轮转失败，而是进程还握着旧的文件描述符。Linux 的文件描述符引用的是打开文件描述，路径名被重命名并不会自动让进程重新执行 open()。排查重点应从“文件名”转到“进程当前打开的对象”。

为什么服务还在写旧文件

可以把日志路径理解成目录项指向 inode 的名字，而不是进程实际持有的对象。open() 返回 fd 后，进程通过 fd 访问打开文件描述；此时再把 /var/log/app.log 重命名为 app.log.1，只是改变了目录中的名字。原 inode 仍被 fd 引用，服务继续写入它，新的 app.log 则可能由 logrotate 按权限创建成另一个 inode。

先找出服务的 PID，再查看它打开的日志对象。下面的命令只做观察，不会改变进程状态：

# 找到服务主进程；实际环境也可以从 systemctl status 中读取 PID
pid=$(systemctl show -p MainPID --value your-service.service)

# 查看该进程打开的日志路径，重点关注 deleted 标记
sudo lsof -nP -p "$pid" | grep -E 'app\.log|deleted'

# 逐个查看 fd 的真实链接，确认它是否仍指向轮转前的文件
for fd in /proc/$pid/fd/*; do
  target=$(readlink "$fd")
  case "$target" in
    *app.log*) printf '%s -> %s\n' "$fd" "$target" ;;
  esac
done

如果看到类似 /var/log/app.log.1 (deleted)，说明目录项已经不存在，但只要 fd 还在，inode 及其磁盘空间就可能继续被占用。不要只用 ls -l app.log 判断服务是否已经切换。

rename 和 copytruncate 的差别

logrotate 的默认思路通常是移动旧文件、创建新文件，再由服务重新打开日志。这个方案不会强迫一个已经打开的 fd 改指向，因此必须有“让服务重开”的动作。copytruncate 则先复制内容，再把原文件原地截断；原 fd 继续指向同一个 inode，所以对不能重开日志的老程序更兼容，但复制和截断之间存在日志丢失窗口。

两种方案都不是“加一个参数就永远正确”。高吞吐服务优先选择可控的 reopen，因为它能把新文件的权限、所有者和写入边界说清楚；确实无法重开时，再接受 copytruncate 的兼容性代价。

让服务在轮转后重新打开日志

服务必须明确支持哪种信号。以能通过 HUP 重新打开日志的服务为例，配置的关键不是信号名称本身，而是让动作发生在轮转完成后，并且只对这一组日志执行一次：

/var/log/your-service/app.log {
    daily
    rotate 7
    missingok
    notifempty
    create 0640 appuser adm
    sharedscripts
    postrotate
        # 发送服务文档规定的重开信号，不要盲目替换成 reload
        systemctl kill -s HUP --kill-who=main your-service.service
    endscript
}

若服务采用自己的控制命令，就把 postrotate 中的动作替换为该命令；若服务由 systemd 管理，也要确认它的主进程确实接收信号。不要把“重启成功”误当成“日志重开成功”，两者的资源代价和可用性影响不同。

用清单完成配置与反向验证

1. 确认轮转配置匹配的是当前日志路径，没有把已经轮转的 *.1 再次纳入通配范围。
2. 确认新文件的用户、组和模式与服务进程一致；权限错误会让“重开失败”看起来像信号没有生效。
3. 轮转后再次执行 lsof 或检查 /proc/PID/fd，确保 fd 指向当前 app.log，不再显示 deleted。
4. 观察一段写入周期：新文件增长，旧文件大小稳定，再执行压缩或删除。

如果旧文件仍增长，优先检查服务日志中的 reopen 错误、postrotate 的退出码、主进程 PID 是否变化，以及轮转动作和服务动作之间的权限边界。

常见问题

为什么删除日志文件后磁盘空间没有马上释放？

目录项删除不等于 inode 立即释放。进程仍持有 fd 时，文件内容还在；找到对应 PID 并让服务正确关闭或重开 fd 后，空间才会回收。

copytruncate 能完全避免日志丢失吗？

不能。复制和原地截断之间存在并发写入窗口，极高写入量场景还可能受到复制速度影响。它是兼容性方案，不是无损保证。

postrotate 里直接 restart 服务可以吗？

可以作为明确的运维取舍，但通常比服务原生 reopen 更重。先查服务文档，能平滑重开就优先使用支持的信号或控制命令。