Linux 用 logrotate 管理应用日志：轮转、压缩与安全验证

Linux 用 logrotate 管理应用日志：轮转、压缩与安全验证教程示意图

适用场景

自建脚本或小型服务持续向普通文本文件写日志，而文件越来越大时，可以用 logrotate 定期改名、压缩和淘汰旧文件。本教程的成果是为一个已有应用建立独立规则，并在不等待定时任务的情况下安全验证。它不适用于只写入 systemd journal 的服务，也不建议接管已经由软件自身管理的日志。

原理

logrotate 根据配置文件和状态文件判断某个日志是否满足轮转条件。轮转通常把当前文件改名，再创建新的空文件；随后应用必须重新打开日志路径，否则它可能继续向已改名的旧文件描述符写入。postrotate 可通知支持重新打开日志的服务。copytruncate 则先复制再截断原文件，应用无需重开，但复制与截断之间存在丢失少量日志的窗口，所以只应作为无法通知应用时的折中方案。logrotate 通常由 cron 或 logrotate.timer 周期调用，配置了 hourly 并不意味着系统一定每小时执行它。

准备工作

确认日志文件的真实路径、写入进程、文件所有者和应用是否支持收到 HUP 后重新打开日志。先检查磁盘剩余空间，并把需要保留的现有日志复制到受控备份位置。下面以 /var/log/<应用名>/app.log 表示目标路径，<应用名>不是可以直接照抄的目录名。操作需要 sudo 权限；不要把密码写进脚本或配置。

分步骤操作

查看安装状态、调度方式和目标文件属性：

logrotate --version
systemctl status logrotate.timer
ls -l /var/log/<应用名>/app.log

将<应用名>替换为实际应用目录。如果系统没有 systemd 定时器，应检查发行版提供的 cron 配置，而不是重复创建第二套调度。

检查全局配置是否已经包含 /etc/logrotate.d：

sudo logrotate --debug /etc/logrotate.conf

--debug只打印判断过程，不轮转日志，也不更新状态文件，适合先发现重复规则和语法错误。

使用具备提权保存能力的文本编辑器，新建 /etc/logrotate.d/<应用名>。文件名中的<应用名>替换为简短、无空格的真实名称。可从以下规则开始：

/var/log/<应用名>/app.log {
    size 20M
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 <日志用户> <日志组>
}

路径必须替换为真实日志文件；<日志用户>与<日志组>应取自前面 ls -l 的结果或应用官方要求。size 20M表示超过约 20 MB 时可轮转，rotate 7保留七个旧版本，delaycompress让最新的旧文件延后一轮压缩，missingok允许文件暂时不存在，notifempty跳过空文件，create按给定权限建立新文件。不要为了省事使用 0666 等全员可写权限。

如果应用明确支持重新打开日志，可在右花括号前加入经该应用官方文档确认的通知：

    sharedscripts
    postrotate
        systemctl kill -s HUP <服务单元>
    endscript

<服务单元>替换为真实 systemd 单元名。不要猜测信号；某些程序收到 HUP 会重新加载全部配置，另一些程序可能退出。如果无法确认，就先在测试环境验证，或采用应用官方提供的轮转方式。

再次执行只读调试，并仔细检查目标文件、判定条件和错误：

sudo logrotate --debug /etc/logrotate.d/<应用名>

确认无误后，选择低流量时段进行一次强制演练：

sudo logrotate --force --verbose /etc/logrotate.d/<应用名>

--force忽略时间或大小条件，会真正改动日志，只能在已备份且确认规则只匹配目标文件后使用。

验证方法

执行后查看目录：

ls -lh /var/log/<应用名>/
systemctl status <服务单元>

应出现新的 app.log 和轮转版本，新文件的属主、属组及权限应正确。让应用产生一条正常业务日志，再确认内容进入新的 app.log，而不是继续增长旧文件。还应检查 logrotate 的退出码以及 systemd 日志，确认 postrotate 没有失败。第二轮后才看到最新旧文件压缩，是 delaycompress 的正常行为。

常见错误

报权限不安全，常因配置文件可被普通用户写入，或日志目录由非特权用户控制却没有合适的 su 策略。轮转后新日志为空而旧文件继续增长，说明应用没有重新打开文件。通配符写得过宽可能把 .1 或 .gz 再次匹配，应优先写精确路径。首次运行时间型规则可能只记录状态而不立即轮转；这不是故障。size与时间条件的先后和组合会影响判断，初学者应先选一种清晰条件。

安全与回退

保留修改前的规则副本和日志备份。若演练失败，先停止继续强制轮转，恢复原规则，并确认应用仍能写入当前文件。误用信号导致服务异常时，应依据该服务的正常启动流程恢复，而不是反复发送信号。不要直接删除未知的旧日志来腾空间；它们可能仍被进程占用或有审计价值。生产环境中应先在单个低风险应用上观察至少一个完整轮转周期，再逐步推广。