logrotate 配置未生效主因是定时器未触发或规则未被加载；需检查 logrotate.timer 状态、/etc/logrotate.d/ 下文件权限与 include 路径；按大小轮转须避免与 daily 冲突，推荐使用 size、copytruncate、notifempty 和 missingok；journald 和 Docker 日志需分别通过 journald.conf 和 daemon.json 限流。
logrotate 配置写了却没轮转？先查定时器有没有跑
日志文件持续膨胀、logrotate -d /etc/logrotate.conf 手动执行又一切正常——这基本说明配置根本没被触发。不是规则写错了，是压根没进调度队列。
-
systemctl list-timers | grep logrotate：新版 systemd 默认启用logrotate.timer，如果没看到，说明定时器没注册或被禁用 -
ls -l /etc/logrotate.d/：确认你的规则文件（比如myapp）确实在这个目录下，且权限是644（不能是600或755） -
grep -r "include" /etc/logrotate.conf：必须有include /etc/logrotate.d这一行，否则所有/etc/logrotate.d/下的文件都会被忽略
按大小切日志，别迷信 daily
一天 1KB 和一天 8GB 的日志，硬按时间轮转毫无意义。用 size 才能真正控住单个文件体积，但参数之间有冲突，一错就失效。
-
size 100M和daily不能共存：只要写了daily，logrotate 就只看时间，size形同虚设 -
copytruncate是关键：应用不重开日志句柄时，必须用它，否则轮转后原进程还在往已清空的旧文件写，磁盘空间不释放 -
notifempty和missingok建议常驻：避免空日志或临时缺失路径导致整个轮转流程中断
示例规则：
/var/log/myapp/app.log {
size 100M
rotate 7
compress
delaycompress
copytruncate
notifempty
missingok
}
journald 占满几十 GB？别删文件，改配置再 vacuum
/var/log/journal/ 突然飙到 30GB+，不是磁盘坏了，是 systemd-journald 根本没设上限。直接 rm -rf /var/log/journal/* 不但白干，重启后还会重新索引旧日志。
- 编辑
/etc/systemd/journald.conf，取消注释并设置：SystemMaxUse=512M（建议 256–1024M 区间）MaxRetentionSec=2week（控制保留时长） - 生效命令：
sudo systemctl restart systemd-journald - 立即释放空间：
journalctl --vacuum-size=512M或--vacuum-time=2d，比删文件安全十倍
Docker 容器日志爆满？从 daemon.json 开始堵漏
一个容器几小时内打满宿主机磁盘，大概率是 Docker 默认的 json-file 日志驱动没加限制。这不是应用问题，是运行时配置缺位。
- 在
/etc/docker/daemon.json中加入：
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
- 重启生效：
sudo systemctl restart docker - 验证是否加载：
docker inspect <container_id> --format='{{.HostConfig.LogConfig}}'</container_id>，输出里必须包含max-size和max-file - 注意：
max-size是单个日志文件上限，max-file是保留份数，超出后自动轮替删除最老的
真正容易被忽略的是：容器日志路径（/var/lib/docker/containers/<id>/<id>-json.log</id></id>）不在 /var/log 下，常规 logrotate 规则扫不到——必须靠 Docker 自身驱动来管。
