PHP日志清理验证技巧与方法

验证PHP日志是否被真正清理，关键不在于文件是否存在或大小归零，而在于确认旧日志是否彻底停止写入、磁盘空间是否真实释放——这需要综合检查inode变化、lsof查看PHP进程是否仍持有旧日志句柄、df与du对比排查空间滞留、tail和journalctl实时观察写入行为，并针对logrotate配置（如copytruncate生效与否）、PHP-FPM重载机制、应用层日志（如Monolog）的保留策略及权限问题进行穿透式核验；实践中，大量“清理失败”的本质是“清理执行了但未生效”，根源常在于进程未响应信号导致句柄泄漏，或错误日志在崩溃循环中疯狂写入，因此必须从内核级（inode、文件句柄）和运行时（进程行为、实时写入流）双维度交叉验证，才能避免磁盘爆满的线上危机。

怎样确认 logrotate 是否真正清理了 PHP 日志

直接看日志文件是否存在或大小是否归零，往往不准——因为 logrotate 默认用 copytruncate 或重命名方式处理，原文件句柄可能仍被 PHP-FPM 或 Apache 持有。验证重点不是“文件删没删”，而是“旧日志内容是否还在写入、磁盘空间是否释放”。

• 执行 ls -lh /var/log/php*.log* 查看文件时间戳和大小，但注意：access.log.1 这类归档文件存在是正常的，关键看 access.log（当前活跃文件）是否被截断或重建
• 用 lsof -n -p $(pgrep php-fpm | head -1) | grep log 检查 PHP 进程是否还持有着已轮转的日志文件（如 access.log.1），若存在，说明它仍在往旧文件写，copytruncate 未生效或配置漏 reload
• 对比 df -h /var 和 du -sh /var/log/php*.log*，如果 df 显示空间未释放，但 du 总和很小，大概率是进程没释放句柄，需 kill -USR1 或重启 PHP-FPM

PHP 应用层日志（如 Monolog）如何验证清理结果

框架或自定义日志（如 Laravel 的 storage/logs/laravel.log）不走 logrotate，得靠应用自身策略或外部脚本清理。验证核心是：清理逻辑是否被执行、保留策略是否准确、是否误删正在写的日志。

• 检查清理命令是否带 --dry-run（如 find storage/logs -name "*.log" -mtime +7 -delete 改成 -print 先试跑）
• 确认 PHP 进程没以 root 身份运行却写日志到非 root 可删目录，否则 crontab 用 www-data 清理会因权限失败，日志越积越多
• Monolog 的 RotatingFileHandler 默认按天轮转，但不会自动删除旧文件；若启用了 $handler->setFilesToKeep(5)，需验证实际保留数是否严格 ≤5，注意它只在新日志创建时触发清理，不是定时任务

常见误判：明明跑了清理脚本，日志目录还是爆满

根本原因常不在“没清理”，而在“清了但没生效”或“边清边写得更快”。尤其当 PHP 错误日志开启 error_log = /var/log/php-error.log 且未配置 logrotate，又遇上无限循环报错，几秒就能写满 GB 级日志。

• tail -f /var/log/php-error.log 实时观察是否还有新行涌入，比看磁盘空间更直接
• 检查 php.ini 中 log_errors 和 error_log 是否启用，某些环境误开 log_errors = On 但 error_log 指向一个不可写路径，PHP 会退回到 stderr，而 Web 服务器（如 Nginx）可能把 stderr 合并进 access log，造成日志膨胀假象
• 用 journalctl -u php*-fpm -n 50 查看 FPM 自身错误，有时子进程崩溃反复重启，导致日志句柄泄漏+重复写入

用 stat 和 inotifywait 做轻量级清理后核验

适合 CI/CD 部署后或运维巡检时快速确认：日志文件是否真的被轮转/截断，而不是仅改名。

• 清理前记下当前日志的 inode：stat -c "%i" /var/log/php-access.log
• 触发 logrotate -f /etc/logrotate.d/php 后再查 inode，若变了，说明是 rename 方式轮转；若不变但大小为 0，说明是 copytruncate 成功
• 用 inotifywait -m -e create,move_self /var/log/ 监听目录，可直观看到 php-access.log.1 是否生成、php-access.log 是否被 move_self（即被重命名）

真实环境中，最常被忽略的是 PHP 进程未响应 SIGHUP 或 USR1，导致轮转后仍往旧文件写——哪怕 logrotate 报告成功，磁盘空间也不会释放。核验必须落到进程行为和 inode 变化上，不能只信文件列表。

今天关于《PHP日志清理验证技巧与方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！