logrotate是否生效需先确认其是否被cron调度：检查systemctl status cron、grep日志记录、用-d/-t调试配置，并验证/etc/logrotate.d/下服务规则是否存在且语法正确，避免日志失控增长。

直接看 logrotate 是否在管日志，而不是等磁盘 100% 后再猜。

确认 logrotate 是否生效

logrotate 不是开箱即用的“自动开关”，它依赖 cron 每天调用一次。如果没配、配错或被禁用，日志就只会越写越大。

• 查 cron 是否运行：systemctl status cron 或 systemctl status crond（CentOS）
• 查 logrotate 是否被调度：grep logrotate /var/log/syslog（Ubuntu/Debian）或 grep logrotate /var/log/messages（RHEL/CentOS）——看最近 24 小时有没有执行记录
• 手动触发并观察：logrotate -d /etc/logrotate.conf（-d 是 debug 模式，只模拟不执行），重点看输出里有没有 rotating log 或报错如 skipping ... because parent directory has insecure permissions

检查配置是否存在且正确

/etc/logrotate.d/ 下缺了某服务的配置，等于那部分日志完全没人管。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 列出所有已启用的轮转规则：ls /etc/logrotate.d/，确认 nginx、tomcat、docker、rsyslog 等关键服务是否有对应文件
• 检查某个服务配置是否语法合法：logrotate -t /etc/logrotate.d/nginx（-t 表示 test，不执行只校验）
• 常见错误包括：路径写错（比如写成 /var/log/nginx/access.log，但实际是 /var/log/nginx/access.log 权限不对）、create 指令用户组不存在、postrotate 脚本里 pid 文件路径错误

定位“失控”的日志源头

即使 logrotate 存在，也可能只覆盖了部分日志，漏掉第三方或自研应用的日志目录。

• 快速扫一遍日志大户：du -sh /var/log/* 2>/dev/null | sort -hr | head -10
• 重点关注这些位置：/var/log/journal（journald 默认不轮转）、/var/lib/docker/containers/*/logs（Docker JSON 日志）、/opt/app/logs 或 /home/app/logs（自定义路径）、/var/log/audit（SELinux 审计日志）
• 对异常大的目录，用 ls -lt /var/log/app/ | head -5 看最新文件修改时间——如果全是今天写的、没带日期后缀（如 .1、.2.gz），基本可判定未轮转

验证空间是否真被“已删未释放”卡住

有时候 df 显示 100%，但 du 统计不到对应大小，不是 logrotate 的锅，而是进程还在往已删除的文件写。

• 运行：lsof +L1，找出链接数为 0 的文件（即已被 rm 但句柄未关）
• 典型输出：java 12345 appuser 123w REG 8,1 18G /var/log/app/out.log (deleted)
• 这种情况 logrotate 压根没机会处理——因为文件名已消失，轮转规则匹配不到。必须重启服务或发 SIGHUP 让其 reopen 日志（前提是程序支持）