应修改/etc/systemd/journald.conf中SystemMaxUse=100M并设ForwardToSyslog=no，重启systemd-journald服务生效；journalctl --vacuum-size仅为一次性清理，非永久限制。
journalctl 日志大小限制怎么设
systemd-journald 的日志大小由 journald.conf 控制，不是靠 ulimit 或 logrotate。直接改配置文件最稳妥，改完必须重启服务才生效。
编辑 /etc/systemd/journald.conf，取消注释并修改这两行：
SystemMaxUse=100M ForwardToSyslog=no
其中 SystemMaxUse 是核心参数，表示 journal 总占用上限（支持 K/M/G 单位）；ForwardToSyslog=no 可避免日志被双写到 /var/log/messages，减少冗余。
- 改完执行
systemctl restart systemd-journald，否则不生效 - 重启后用
journalctl --disk-usage验证是否已收紧 - 如果看到 “No space left on device” 类错误，说明
SystemMaxUse设得太小，或磁盘本身已满
/var/log/messages 等传统日志大小怎么控
rsyslog 本身不控制单个文件大小，靠 logrotate 的 size 参数实现。不能只改 /etc/logrotate.conf 全局设置，得在对应服务的配置里加。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
比如限制 /var/log/messages 单个文件不超过 50M，编辑 /etc/logrotate.d/rsyslog，把原配置改成：
/var/log/messages {
daily
size=50M
rotate 7
compress
missingok
notifempty
create 640 root adm
}
size=50M 是关键，它比 daily 优先级更高：只要文件达到 50M 就立即轮转，不管是否过了一天。
- 改完运行
logrotate -f /etc/logrotate.d/rsyslog立即测试效果 - 注意
size不支持小数，也不能写成50 MB（必须是50M） - 若日志增长极快，建议同时配
maxsize（某些新版 logrotate 支持），但 CentOS 7 默认不识别
为什么 journalctl --vacuum-size 不算“永久修改”
journalctl --vacuum-size=100M 是一次性命令，只清理当前已存在的日志，不改变后续行为。它适合应急缩容，但无法替代 journald.conf 的持久配置。
- 下次系统重启或 journal 文件重建后，仍按原配置积累
- 如果你发现日志又涨回 2G，说明
SystemMaxUse没设或设得太大 - 别混用：
--vacuum-size和SystemMaxUse冲突时，以配置文件为准
容易忽略的磁盘空间陷阱
日志清理后空间没释放？常见原因不是命令没跑，而是文件被进程锁住。
- 用
lsof +L1查看是否有被删除但仍被打开的日志文件（状态为DEL） - 典型场景：
rsyslogd进程还在往已清空的/var/log/messages写，但文件 inode 已被 truncate，空间实际未归还 - 解决办法：重启
rsyslog（systemctl restart rsyslog）或发SIGHUP让它重新打开文件 - journal 日志不会出现这种问题，因为 journald 自己管理 mmap 文件
