PHP日志清理后error_log索引不更新，是因为进程仍持有原文件句柄，持续写入已删除的inode；解决方法是让PHP重开日志文件：FPM用kill -USR2、Apache重启、CLI需手动fclose/reopen。
PHP 日志清理后 error_log 索引不更新？其实是文件句柄没释放
PHP 进程（尤其是常驻的 FPM worker 或 CLI 长进程）在写日志时，会持有一个指向日志文件的文件描述符。即使你用 rm 或 truncate 清空了磁盘上的 error.log，只要 PHP 进程没重启，它仍在往“原文件”（已被 unlink 但未关闭的 inode）里追加内容——新日志根本不会出现在你刚创建的空文件里，索引自然“失效”。
这不是 PHP 的 bug，是 Unix 文件系统的正常行为。解决的关键不是“重建索引”，而是让 PHP 重新打开日志文件：
- 对 PHP-FPM：执行
sudo systemctl reload php-fpm（或kill -USR2主进程），触发 worker 进程优雅重启，新进程会打开新的error_log文件 - 对 Apache + mod_php：重启 Apache（
sudo systemctl restart apache2），因为日志由 Apache 主进程控制 - 对 CLI 脚本：无法自动恢复，必须确保脚本自身在日志轮转后主动
fclose($fp); $fp = fopen(..., 'a');
用 logrotate 自动清理时，必须配 create 和 sharedscripts
直接 rm 日志文件会中断写入，logrotate 是更安全的选择，但它默认不处理 PHP 进程重开日志的问题。
典型配置（如 /etc/logrotate.d/php-fpm）应包含：
立即学习“PHP免费学习笔记（深入）”；
/var/log/php-fpm/www-error.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 0644 www-data www-data
sharedscripts
postrotate
if [ -f /var/run/php/php-fpm.pid ]; then
kill -USR2 `cat /var/run/php/php-fpm.pid`
fi
endscript
}
create 确保新文件权限正确；sharedscripts 保证 postrotate 只运行一次（避免多个 worker 同时发信号）；kill -USR2 是 PHP-FPM 支持的平滑重载信号，比 reload 更精准。
别信“touch 日志文件就能刷新索引”这种说法
有人尝试 touch /var/log/php-fpm/www-error.log，以为能“唤醒” PHP。实际毫无作用——PHP 不监听文件变更，也不轮询文件状态。只要文件描述符还开着，它就继续往旧 inode 写。
验证是否真在写新文件？运行：lsof -p $(pgrep php-fpm) | grep log
看输出中的文件路径和 inode 号。如果显示的是 www-error.log (deleted)，说明还在写已删除文件；如果显示正常路径且无 (deleted)，才表示已切换成功。
自定义日志写入（error_log() 或 Monolog）需手动管理文件句柄
如果你用 error_log($msg, 3, '/path/to/app.log') 或 Monolog 的 StreamHandler，PHP 不会自动感知日志文件被清空或轮转。这类场景下，“索引更新”完全取决于你的代码逻辑：
- Monolog：用
RotatingFileHandler，它会在每次写入前检查文件大小并自动轮转，无需外部干预 - 原生
error_log()：无法自动恢复，建议改用fopen()+fwrite()并在捕获ENOENT错误后重试打开 - 长周期 CLI 任务：定期检测文件 inode 是否变化（
fileinode($path)对比缓存值），变化则fclose+fopen
真正的难点从来不在“怎么删日志”，而在于“删完之后，谁来告诉 PHP：嘿，换条新路走”。这个“谁”，要么是运维信号（USR2/reload），要么是日志库的内置机制，要么是你自己写的 inode 检测逻辑——没有银弹，只有匹配场景的明确动作。
