maxage仅按mtime删除logrotate生成的规范归档文件，不处理自定义索引；需在postrotate中用find单独清理，或结合rotate与dateext提升可靠性。
Logrotate 的 maxage 参数本身**不负责清理“无效的归档索引”**，它只按文件最后修改时间（mtime）删除超过指定天数的**已轮转日志文件**（如 app.log.1, app.log.2.gz 等），且仅作用于被 logrotate 管理并命名规范的日志归档文件。它无法识别或处理所谓“冗余归档索引”——因为 logrotate 本身不生成、不维护、也不知晓任何“索引”概念。
明确 maxage 的实际作用范围
maxage N 表示：对当前配置块中定义的每个日志路径，logrotate 会扫描其所在目录下所有符合该日志基础名 + 数字/日期后缀模式的归档文件（例如 access.log 对应的 access.log-20241001.gz, access.log.1, access.log.2.gz），并删除其中 mtime 超过 N 天的那些文件。
它不处理：
- 非 logrotate 生成的文件（如手动 cp/mv 的备份、脚本生成的 index.json）
- 没有标准归档后缀的文件（如
app.log.index.bak） - 损坏但时间未超期的文件（logrotate 不校验内容有效性）
- 符号链接、空文件、权限异常文件（除非导致 stat 失败而跳过）
若你指的“归档索引”是自定义元数据文件
比如你的归档流程额外生成了 archive_20241001.idx 或 logs_index.sqlite，这些不属于 logrotate 管理范畴。你需要单独清理：
- 在 logrotate 的
postrotate脚本中添加清理逻辑，例如：postrotate<br> find /var/log/archives -name "*.idx" -mtime +30 -delete<br> find /var/log/archives -name "logs_index.sqlite" -mtime +90 -delete<br>endscript
- 确保
postrotate中的命令有足够权限读取目标目录和文件 - 先用
find ... -print测试匹配是否准确，再加-delete
若你遇到“过期但未被 maxage 删除”的情况
常见原因及应对：
-
文件 mtime 被意外更新：如用
touch、解压、编辑等操作重置了时间。改用maxage配合dateext+dateformat，按文件名中的日期判断更可靠 -
归档文件命名不规范：logrotate 只识别它自己生成或约定格式的文件。检查
logrotate -d /etc/logrotate.d/yourconf输出，确认哪些文件被实际匹配 -
权限不足导致 stat 失败：logrotate 跳过无法获取 mtime 的文件。用
ls -ld检查目录权限，确保运行用户（通常是 root）可遍历 -
maxage 与 rotate 冲突：例如
rotate 5和maxage 30同时存在时，rotate 先限制数量，maxage 再按时间过滤。二者是叠加生效，不是互斥
推荐组合策略保障清理可靠性
不要只依赖单一机制：
- 主日志用
rotate N控制保留份数 - 加
maxage M设置绝对过期时间兜底（M ≥ N × 单次轮转周期） - 对自定义索引/元数据文件，在
postrotate或独立定时任务（crontab）中用find -mtime +K清理 - 定期用
logrotate -d -f /path/to/conf手动调试，观察匹配与删除行为
