答案是存在已删除但进程仍持有句柄的日志文件；执行lsof +l1查找del标记文件，重启php-fpm或nginx释放句柄，或用truncate -s 0安全清空日志内容。
磁盘已满但 du 找不到大文件？先查被删仍打开的日志句柄
PHP 日志写满磁盘后，df -h 显示 100%，但 du -sh /var/log/*.log 加起来才几 MB——这基本就是日志文件已被 rm 删除，但 PHP-FPM 或 Apache 进程仍在往其 inode 写入。系统空间没释放，ls 看不见，du 统计不到。
立刻执行：lsof +L1，重点看输出中含 DEL 标记的行，尤其是 php-fpm、apache2、nginx 进程关联的条目。
- 找到对应 PID 后，用
lsof -p <pid></pid>确认具体路径（例如/var/log/php-error.log (deleted)） - 稳妥做法是重启服务：
systemctl restart php-fpm（或nginx），释放句柄并重建日志文件 - 若不能重启，可尝试
kill -USR1 <pid></pid>—— 仅当 PHP-FPM 配置了catch_workers_output = yes且启用了平滑重载日志时才有效
error_log 文件本身超 GB 怎么快速清空又不中断写入
直接 rm /var/log/php-error.log 会导致后续日志丢失（进程还在写原 inode），而 truncate -s 0 /var/log/php-error.log 是更安全的选择：它清空内容但保留文件路径和 inode，所有正在写入的进程不受影响。
- 确认文件权限与 PHP-FPM 运行用户一致（如
www-data:www-data），否则truncate可能失败 - 清空前建议先
cp /var/log/php-error.log /tmp/php-error.log.bak备份最近内容（如果磁盘还有几 MB 剩余） - 不要对
slow_query_log或 MySQL 的general_log直接 truncate——它们可能被数据库进程独占打开，需配合SET GLOBAL slow_query_log = OFF再操作
logrotate 没生效？检查三处硬性匹配点
很多 PHP 项目依赖 logrotate 自动轮转，但配置错一处就彻底失效，导致日志越积越大。
- 运行
logrotate -d /etc/logrotate.conf，确认你的日志路径是否被实际匹配到（注意通配符、路径结尾斜杠、软链接解析） - 检查日志文件属主是否与
create指令一致：比如 PHP-FPM 以www-data运行，但配置里写了create 0644 root root，轮转后新文件无法写入，旧文件被迫一直追加 - 避免滥用
copytruncate：它只是清空原文件内容，不移动文件，适合无法中断写入的场景；但会掩盖突发错误（比如某次写入失败后，后续日志全丢），建议只在紧急兜底时启用
auditd 或 systemd-journald 也在偷偷吃空间？别只盯 PHP
PHP 日志只是表象，df -h 显示根分区满，但 /var/log 目录不大？那可能是其他系统级日志在撑爆磁盘。
- 查
journalctl --disk-usage，若显示几百 MB 以上，执行journalctl --vacuum-size=200M限制日志体积 - 运行
ausearch -m avc --start today | wc -l和ausearch -m SYSCALL --start today | wc -l，若返回值超万条，说明auditd正高频记录（比如误配了-S execve），需禁用非必要 syscall 监控 - 检查
/var/log/audit/audit.log是否存在且巨大，确认space_left = 250和max_log_file = 10是否已设，否则 auditd 不会自动轮转或告警
真正危险的不是单个日志文件大小，而是多个日志源（PHP、MySQL、auditd、journald）同时失控——必须逐个验证，不能只清 php-error.log 就以为万事大吉。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
