logrotate仅加载/etc/logrotate.conf和/etc/logrotate.d/下非隐藏、无扩展名文件；daily是触发条件，rotate n控制保留份数；compress需与delaycompress、copytruncate配合使用；手动测试用logrotate -f或-d，生产环境需谨慎。
logrotate 配置文件必须放在 /etc/logrotate.d/ 或 /etc/logrotate.conf
logrotate 不会读取任意路径的配置文件。它只加载 /etc/logrotate.conf（主配置）和 /etc/logrotate.d/ 目录下所有非隐藏、无扩展名的文件。把配置丢进 /root/ 或 /opt/conf/，crontab 里跑再多遍也不会生效。
常见错误是手动写了个 syslog.conf 放在别处，然后反复执行 logrotate -f 却没反应——根本没被加载。
- 确认配置已落盘：
ls -l /etc/logrotate.d/看文件是否存在且权限为 644 - 检查主配置是否包含
include /etc/logrotate.d（默认就有，删了就失效） - 不要用
.bak、.old或.txt后缀，logrotate 会跳过它们
daily + rotate 30 不等于“保留30天”，而是最多存30个归档文件
daily 是触发条件，不是保留策略；rotate 30 才管保留份数。比如某服务日志隔天才写一次，那即使设了 daily，实际可能两天才轮转一次，但依然只留最近 30 个 .log.1、.log.2….log.30 文件。
如果你真想按“天数”清理（比如只留最近 30 天的压缩包），不能只靠 rotate，得额外用 find：
- logrotate 负责生成
/var/log/app.log.1.gz这类带编号的归档 - 再配一条 cron：
0 2 * * * /usr/bin/find /var/log -name "app.log.*.gz" -mtime +30 -delete - 务必用绝对路径调用
find，cron 环境里$PATH很窄
compress 和 delaycompress 必须配合 copytruncate 使用
很多服务（如 nginx、java 应用）无法优雅重开日志文件，只能靠 copytruncate：先拷贝再清空原文件。这时如果只写 compress，logrotate 会在拷贝后立刻 gzip 原文件——而此时应用还在往新文件写，刚拷贝出来的内容可能是不完整的，gzip 后解压失败。
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
正确做法是同时启用：
-
copytruncate：确保服务不中断 -
delaycompress：本次轮转不压缩，等下次轮转时再压缩上一轮的归档 -
compress：仍要保留，否则delaycompress不生效
示例片段：
/var/log/myapp/app.log {
daily
missingok
rotate 14
compress
delaycompress
copytruncate
notifempty
}
手动测试必须用 logrotate -f，但别在生产环境乱跑
logrotate -d /etc/logrotate.conf 只模拟，不真实操作，适合看逻辑是否通；logrotate -f /etc/logrotate.d/myapp 是强制立即执行，能验证归档、压缩、postrotate 是否真生效。
但注意：
- 别对全局配置用
-f，可能触发所有服务轮转，造成 I/O 尖峰 - 生产环境执行前，先停掉 cron 中的 logrotate 任务（注释掉
/etc/cron.daily/logrotate），避免冲突 - 观察
ls -lt /var/log/*.gz和zcat /var/log/app.log.1.gz | head -5确认内容可读
真正容易被忽略的是 postrotate 里命令的路径和权限——比如 systemctl reload myapp 在 cron 下找不到 systemctl，得写成 /usr/bin/systemctl reload myapp。
