journalctl 日志按天清理需分版本处理：systemd≥230用MaxRetentionSec=7d，否则用MaxFileSec+SystemMaxUse组合并手动执行journalctl --vacuum-time=7d；syslog日志通过logrotate配置daily和rotate 90实现90天保留。
journalctl 日志怎么按天数自动清理
不能只改 MaxRetentionSec 就完事——它在 CentOS 7（systemd 219）等老系统上根本不存在，强行写进去会被忽略。必须先确认 systemd 版本：systemd --version。≥230 才支持该参数；低于这个值，得靠 MaxFileSec + SystemMaxUse 组合兜底。
真正起效的配置只有三步：改 /etc/systemd/journald.conf → 重启 systemd-journald → 手动执行 journalctl --vacuum-time=7d。跳过最后一步，旧日志照常躺在 /var/log/journal/ 里，新策略只管后续写入。
-
MaxRetentionSec=7d：强制删除早于 7 天的日志（优先级最高） -
MaxFileSec=1d：单个日志文件最多存 1 天（影响轮转频率，不等于总保留时长） -
SystemMaxUse=512M：防止单次突发日志打爆磁盘，和时间策略配合更稳
/var/log/ 下的 syslog 日志怎么设保留 90 天
这类日志走的是 logrotate 路线，不是 journald。核心就两个字段：daily 和 rotate 90。前者决定轮转频率，后者决定保留多少份——每天轮一次，留 90 份，自然就是 90 天。
别去改 /etc/rsyslog.conf 里的 $SystemLogRotateDays，那是 rsyslog 自己的旧式轮转开关，现代发行版基本不用，且和 logrotate 冲突。统一用 /etc/logrotate.d/rsyslog 或全局 /etc/logrotate.conf 管理更可靠。
- 编辑
/etc/logrotate.d/rsyslog，确保有daily和rotate 90 - 检查
/var/lib/logrotate/status，确认上次轮转时间是否符合预期 - 运行
sudo logrotate -d /etc/logrotate.conf可模拟执行，看是否报路径不存在或权限错误
为什么改了配置但旧日志还在
因为 journald 不热加载，logrotate 也不自动回溯清理。journald 的 MaxRetentionSec 只约束新写入日志的生命周期，已有日志不会自动删；logrotate 的 rotate N 只在下次轮转时才删超限的旧副本。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
所以你看到 journalctl --since "7 days ago" 能查到数据，不代表系统已清理——那只是查询过滤，不是物理删除。真正删掉要靠 --vacuum-time 或等下一轮 logrotate 触发。
- journald：必须手动跑
sudo journalctl --vacuum-time=7d - logrotate：可加
olddir /var/log/old把待删日志先挪走，方便临时恢复 - 两者都不支持“立即删光所有早于 X 天的日志”，只能靠策略+触发+验证
CentOS 7.9 这种老系统要注意什么
它用的是 systemd 219，MaxRetentionSec 不识别。硬加会静默失效。此时唯一靠谱方案是：设 MaxFileSec=1d + SystemMaxUse=512M + 定期 cron 清理。
还要注意 /var/log/journal/ 目录默认不存在，journald 不会自动创建。得手动建目录并补 SELinux 上下文：
sudo mkdir -p /var/log/journalsudo systemd-tmpfiles --create --prefix /var/log/journal- RHEL/CentOS 上若启用了 SELinux，需运行
sudo restorecon -Rv /var/log/journal
最麻烦的点其实是验证——journalctl --list-boots 显示的最早启动记录，才是真实生效的保留边界，不是看配置写了多少天。
