ubuntu与centos的logrotate配置语法存在显著差异：路径规则（如ubuntu用/var/log/syslog而centos用/var/log/messages）、默认参数启用（如dateext/compress）、版本兼容性（centos 7的maxsize需配合daily）、权限控制（centos需显式su指令）、journald持久化策略及cron执行环境均不同，导致配置不可直接复用。
logrotate 配置语法差异直接导致切割行为不一致
Ubuntu 和 CentOS 都用 logrotate 做日志轮转，但默认配置路径、模板写法、甚至触发时机都不同，不是改个路径就能复用。最常见问题是：在 Ubuntu 上跑正常的 logrotate 配置，丢到 CentOS 上可能完全不执行，或者切割后没压缩、没删旧文件。
关键区别点：
- Ubuntu 默认主配置是
/etc/logrotate.conf，但大量服务日志规则实际放在/etc/logrotate.d/下的独立文件里（如/etc/logrotate.d/rsyslog）；CentOS 同样用该目录，但其rsyslog规则常被整合进/etc/logrotate.d/syslog，且默认启用dateext和compress更保守 - Ubuntu 的
logrotate版本通常较新（如 3.2.x），支持maxsize、copytruncate等参数更宽松；CentOS 7 自带的 3.8.6 实际对maxsize解析有 bug，需加daily才生效 - CentOS 默认启用
su root root（要求明确指定用户/组），而 Ubuntu 默认以 root 身份运行，不写这行也可能成功——但一旦你在 CentOS 配置里漏掉，postrotate脚本里调用systemctl reload rsyslog就会因权限失败
systemd-journald 日志共存时，journalctl 和文件日志的切割关系容易混淆
Ubuntu 20.04+ 和 CentOS 7+ 都默认启用 journald，但它和传统 /var/log/*.log 是两套系统。很多人以为关掉 journald 就能只靠 logrotate，其实不然。
真实影响：
- Ubuntu 默认把
journald日志持久化到/var/log/journal/，该目录本身也受systemd-journald自身的SystemMaxUse限制，和logrotate无关；CentOS 7 默认不持久化，journalctl只读内存日志，重启即丢——所以你切了/var/log/messages，却查不到昨天的journalctl -u nginx，不是logrotate没切好，是根本没落盘 - 若手动启用了
Storage=persistent，CentOS 的/var/log/journal/目录权限是drwxr-sr-x root systemd-journal，普通logrotate进程无法递归清理，必须用su root systemd-journal或改用systemd-tmpfiles清理 -
logrotate对journald无感知，它只管文件。别指望create 644 syslog adm能影响 journal 文件权限
rsyslog 输出目标不同，导致要切的日志文件名都不一样
Ubuntu 默认 rsyslog 配置把内核日志写进 /var/log/kern.log，而 CentOS 默认只写 /var/log/messages 和 /var/log/secure，kern.log 根本不存在——你照着 Ubuntu 的 logrotate.d/rsyslog 去 CentOS 上找这个文件，当然报错 “No such file or directory”。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
典型路径差异：
- Ubuntu：
/var/log/syslog（主日志）、/var/log/kern.log、/var/log/auth.log - CentOS：
/var/log/messages（通用）、/var/log/secure（认证）、/var/log/maillog（邮件）、/var/log/audit/audit.log（审计，独立服务） - 这意味着你的
logrotate规则里写的/var/log/syslog，在 CentOS 上必须改成/var/log/messages，否则轮转永远不触发 - 另外，CentOS 的
auditd日志由auditd自己管理，默认每天切一次，不走logrotate；Ubuntu 一般不装auditd，除非显式启用
crontab 触发时机和 logrotate 调用方式实际不统一
虽然文档都说 “logrotate 由 cron 每天执行”，但 Ubuntu 和 CentOS 的 cron 调度位置、执行用户、环境变量都不同，直接决定切割是否静默失败。
实操要点：
- Ubuntu 的定时任务在
/etc/cron.daily/logrotate，是 shell 脚本，调用logrotate /etc/logrotate.conf；CentOS 的同名脚本在相同路径，但内部加了if [ -x /usr/sbin/logrotate ]; then ...判断，如果logrotate被误删或权限不对，Ubuntu 可能报错退出，CentOS 则直接跳过，毫无提示 - CentOS 7 的 cron 默认以
root用户运行，但环境变量极简（PATH=/sbin:/bin:/usr/sbin:/usr/bin），如果你在postrotate里写了systemctl reload nginx，而没写绝对路径/bin/systemctl，在 CentOS 上就失败；Ubuntu 的 cron 环境 PATH 更宽，容易掩盖问题 - 调试时别只看
logrotate -d /etc/logrotate.conf，那只是模拟；真要验证，得手动运行run-parts --report /etc/cron.daily/，并检查/var/lib/logrotate/status里最后更新时间是否变化
真正麻烦的不是语法记不住，而是两个系统在日志这条链路上混用了三套机制：journald、rsyslog、logrotate，它们的开关状态、配置优先级、权限模型全都不对齐。一个配置在 Ubuntu 上“看起来工作”，很可能是因为某一层被默认打开了，换到 CentOS 就断在中间一环——得逐层确认，不能只盯 logrotate 文件本身。
