/var/log/secure 切割频繁主因是 logrotate 配置（如 daily+copytruncate 或误配 size）与实际负载不匹配，或 rsyslog 自身规则干扰；应优先排查触发机制、调整为 minsize/maxsize 混合策略，并检查是否遭暴力扫描。
/var/log/secure 切割太频繁，本质是 logrotate 触发条件过于激进，不是日志本身“有问题”，而是配置和实际负载不匹配。直接调大 rotate 数或改成 weekly 可能掩盖问题，反而导致单个文件过大、排查困难或磁盘突发占满。
检查当前切割是否真由 logrotate 主动触发
先确认是不是 logrotate 在“勤快干活”，而不是其他机制在干扰：
- 运行
logrotate -d /etc/logrotate.d/syslog（或/etc/logrotate.d/rsyslog，取决于发行版），看调试输出里是否真对/var/log/secure执行了轮转 - 查
/var/lib/logrotate/status，搜索secure对应的最后轮转时间，对比系统 cron 实际执行时间（grep logrotate /var/log/syslog） - 注意：某些发行版（如 RHEL/CentOS）的
rsyslog配置可能启用了$ActionFileDefaultTemplate或imfile模块，会自行切分日志，和 logrotate 冲突
识别真实诱因：size 还是 daily + copytruncate？
高频切割最常见于两类配置组合：
-
daily+copytruncate：每天强制截断，但若服务写入极快（如暴力扫描集中爆发），一天内/var/log/secure就涨到几十 MB，下一次daily轮转前，文件已远超预期——表面是“每天切”，实则是“每天切完很快又大”，让人感觉“频繁” -
size 10M类配置误加在 syslog 组里：有些自定义配置把size直接写在全局 syslog 块中，而/var/log/secure又恰好属于该块，结果一过 10MB 就切，完全不受时间约束 - rsyslog 自身规则干扰：检查
/etc/rsyslog.conf和/etc/rsyslog.d/*.conf，是否存在类似if $programname == 'sshd' then /var/log/secure-%$YEAR%%$MONTH%%$DAY%的动态文件名规则，这会导致每条日志都写新文件
调整策略：用 minsize 替代 size，或改用 time + size 混合判断
单纯删掉 size 或拉长周期容易出问题；更稳妥的是让 logrotate “看情况再动”：
- 把原来的
size 10M改成minsize 50M：即“至少得有 50MB，且又到了 daily 时间点，才切”。避免小流量日也天天新建归档 - 保留
daily，但加maxsize 100M：表示“哪怕不到一天，只要文件突破 100MB，立刻切”。防止单日突增撑爆磁盘 - 禁用
copytruncate，改用postrotate发信号：确保 rsyslog 真正关闭旧文件再重建，避免因截断导致日志丢失或指针错乱（尤其在高并发认证场景） - 示例安全配置片段（适用于
/etc/logrotate.d/rsyslog）：/var/log/secure { daily minsize 30M maxsize 150M rotate 14 compress delaycompress missingok notifempty create 600 root root sharedscripts postrotate /usr/bin/kill -HUP $(cat /var/run/syslogd.pid 2>/dev/null) 2>/dev/null || true endscript }
真正关键的点：secure 日志内容本身是否异常
切割频繁往往是症状，不是病因。如果调整配置后仍每天切好几份，必须查日志内容：
- 用
awk '$3 ~ /^sshd/ {print $9}' /var/log/secure | sort | uniq -c | sort -nr | head -5快速看失败登录来源 IP 频次 - 运行
grep "Failed password" /var/log/secure | head -20，确认是否被暴力扫描——此时该做的是封 IP（fail2ban）或加固 SSH，而不是调 logrotate - 注意：
authpriv.*日志级别若被设为debug，也会让secure爆增，检查/etc/rsyslog.conf中相关 facility 的级别设置
