登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  linux

logrotate 的 copytruncate 会不会丢日志:复制窗口与服务重开文件怎么选

来源:17golang原创

时间:2026-09-04 12:20:39 125浏览 收藏

会。copytruncate 的风险不在“复制文件”这一步本身,而在复制完成、原文件被截断之间仍有一个写入窗口。服务继续持有原文件描述符时,轮转程序无法把每一条并发写入都纳入副本。能让服务优雅地重新打开日志时,优先使用默认的重命名加新建文件;只有无法通知服务关闭旧句柄时,才考虑 copytruncate

先记住三点:
  • 支持 HUP、USR1 或 reload 的服务,用 rename/create,并在 postrotate 中通知它重开文件。
  • copytruncate 原地清空 inode,兼容性好,但不能承诺复制窗口内零丢失。
  • 判断是否切换成功,要看进程打开的 inode 和新旧文件的增长情况,不只看文件名。

先判断服务能否重新打开日志

先查服务的文档或启动参数,确认它是否支持 reload、HUP 或 USR1。这个信号的目标不是重启业务,而是让进程关闭旧文件描述符,再按原路径打开新文件。Nginx、部分守护进程和自研服务通常有这种能力,但信号名称不能凭经验套用,必须以该服务的说明为准。

普通 rename/create 轮转的大致顺序是:把 app.log 改名为带日期的旧文件,创建一个权限正确的新 app.log,再通知服务重开。若服务没有执行重开,文件名虽然换了,进程仍可能继续写已经改名的旧 inode,结果就是新文件不增长、旧文件持续变大。

理解 copytruncate 的复制窗口

copytruncate 先复制当前文件,再对原文件执行原地截断。由于 inode 没有更换,继续持有旧描述符的进程仍能写入原路径对应的对象,因此不需要服务配合。这正是它的价值,也是它的边界。

复制期间有新日志写入时,写入可能落在副本之后;复制完成到截断之间又可能出现一小段竞争窗口。最终效果可能是少量记录只留在副本、只留在被截断前的尾部,或者没有进入新旧文件中。高吞吐、审计敏感的日志不应把这种方式当成无损方案。

logrotate 两种轮转策略的选择路径
图1:先按服务是否支持重开日志文件选择 rename/create 或 copytruncate。

分别写出两套 logrotate 配置

服务支持 reload 时,配置重点是创建新文件并发送正确的信号:

/var/log/myapp/app.log {
    daily
    rotate 14
    missingok
    notifempty
    create 0640 myapp adm
    sharedscripts
    postrotate
        systemctl reload myapp.service
    endscript
    compress
    delaycompress
}

create 负责新文件的模式、属主和属组;delaycompress 让刚轮转的文件延迟一轮压缩,便于仍需短暂读取旧文件的程序。若服务只接受 HUP,就把 systemctl reload 换成经过验证的信号命令。

服务完全不能重开文件时,才使用:

/var/log/legacy/app.log {
    daily
    rotate 7
    missingok
    notifempty
    copytruncate
    compress
}

两套方案不要叠加成“copytruncate 加 postrotate 重启”。如果已经能安全 reload,重命名加新建通常更清晰;如果只能 copytruncate,重点是接受它的复制窗口,并通过缩短轮转耗时和合理的日志写入粒度降低风险。

用 debug 和文件描述符检查结果

改配置后先做不执行动作的检查:

sudo logrotate -d /etc/logrotate.d/myapp
sudo lsof -nP -p "$(systemctl show -p MainPID --value myapp.service)" | grep '/var/log/myapp/app.log'

-d 用于观察匹配到的规则、脚本和轮转判断;它不会真正轮转。实际执行后,查看新旧文件的 inode:

stat -c '%i %s %n' /var/log/myapp/app.log /var/log/myapp/app.log.*

rename/create 成功后,服务的打开句柄应指向新文件;copytruncate 则通常仍指向同一个 inode,但活动文件尺寸会回到较小值并继续增长。若旧文件还在增长,说明服务没有重开,不能只靠“目录里出现了新文件”判断成功。

copytruncate 的复制到截断时间线
图2:复制、并发写入和原地截断组成的时间窗口,是 copytruncate 可能丢日志的边界。

处理压缩、权限和高并发误区

生产环境还要核对三件事。第一,轮转后的文件由哪个用户读取和压缩,create 的属主不能让采集进程失去权限。第二,压缩任务不要与仍会读取旧文件的程序冲突,必要时使用 delaycompress。第三,日志写入量很大时,copytruncate 的相对风险会随复制耗时增加;更稳的迁移方向是给服务补上 reopen 能力,或改用支持信号切换的日志库。

可以把验收标准写成一句话:轮转后,新路径确实持续出现新日志,旧路径只保留已完成的历史内容,服务没有异常重启,且轮转脚本返回成功。达不到这一点时,先回到文件描述符检查,不要盲目增加 rotate 数量。

相关问题

copytruncate 一定会丢日志吗?不一定每次都能观察到丢失,但官方语义明确提示复制和截断之间存在很小时间片,因此不能按无损轮转设计。

用了 create 为什么服务还写旧文件?create 只创建新路径,不会替进程关闭旧文件描述符;必须配合服务支持的 reload 或信号。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>