Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

file_exists() returns true for a deleted file in a long-lived FPM worker (PHP 8.5.2, open_basedir enabled) — stat()/is_file()/scandir() disagree

未關閉
#23,544 2 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
48/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
c, php

研究方向

首先,在啟用 open_basedir 的長時間執行 PHP-FPM worker 中重現 HTTP 請求,按照報告中的 file_exists()、clearstatcache()、unlink()、stat()、realpath()、fopen() 和 scandir() 順序執行。比較 PHP 8.5.2 和 8.4.17,並確認該 fix 能讓 file_exists() 在刪除後回傳 false,而不需要結束 worker。

由索引模型根據 Issue 內容生成。

描述

Bug Status: Needs Triage
Description

In a long-lived PHP-FPM worker, after a file has been created, required and then unlink()ed (the WordPress .maintenance cycle), file_exists() keeps returning true for it, while is_file(), stat(), realpath(), fopen() and scandir() all report the file as gone. clearstatcache(true, $path) has no effect; the stale answer survives until the worker process exits. Creating the file again (even empty) clears the state.

The trigger in production is WordPress' updater: it writes ABSPATH/.maintenance, core requires it on every request in wp_is_maintenance_mode(), and the updater unlink()s it when done. Afterwards, some workers still answer file_exists() → true, WordPress does require '.maintenance' and dies with Failed opening required '.../.maintenance'.

The following code, run over HTTP in an affected worker while the file is absent on disk:

<?php
header('Content-Type: text/plain');
$m = __DIR__ . '/.maintenance';
clearstatcache(true, $m);
var_dump(file_exists($m));
var_dump(is_file($m));
var_dump(@stat($m));
var_dump(realpath($m));
var_dump(@fopen($m, 'r'));
var_dump(in_array('.maintenance', scandir(__DIR__), true));
stream_wrapper_restore('file');
var_dump(file_exists($m));
echo shell_exec('test -e ' . escapeshellarg($m) . ' && echo EXISTS || echo MISSING');

Resulted in this output:

bool(true)
bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
bool(true)
MISSING

But I expected this output instead:

bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
bool(false)
MISSING

The shell_exec() child inherits uid, cwd and mount namespace from the worker and confirms the file does not exist, so the kernel is consistent and the true originates inside the PHP process.

Ruled out
  • Filesystem/caching layers: FPM worker and an SSH shell are on the same host (gethostname()), same mount namespace (/proc/self/ns/mnt identical), docroot on a local ext4 mount. From the shell, os.access(path, F_OK) and os.path.exists(path) both return False.
  • OPcache disabled.
  • Custom stream wrappers / auto_prepend_file: only built-in wrappers registered, stream_wrapper_restore('file') changes nothing, auto_prepend_file empty.
  • Realpath cache TTL: state persists far beyond realpath_cache_ttl=120 with no requests in between.
  • Same worker across requests verified with getmypid().
  • PHP 8.4.17 (fpm-fcgi) on the same host and pool configuration: not reproducible; downgrading the pool fixed the issue.
Relevant configuration
  • open_basedir set for the pool (docroot, session and tmp dirs, /tmp:/usr/bin)
  • realpath_cache_ttl=120
  • disable_functions: pcntl_*, leak, dl, stream_socket_server, stream_socket_sendto
  • Extensions: Core, date, lexbor, openssl, pcre, zlib, filter, hash, json, uri, Zend OPcache, random, Reflection, SPL, session, standard, sodium, libxml, cgi-fcgi, apcu, bcmath, bz2, calendar, ctype, curl, dba, dom, fileinfo, ftp, gd, gmp, gettext, iconv, igbinary, imagick, imap, intl, mbstring, exif, msgpack, memcached, mysqlnd, mysqli, pgsql, sqlite3, PDO, pdo_mysql, pdo_pgsql, pdo_sqlite, Phar, posix, redis, shmop, SimpleXML, sockets, sysvmsg, sysvsem, sysvshm, tokenizer, xml, xmlreader, xmlwriter, xsl, soap, zip
PHP Version
8.5.2 fpm-fcgi
Operating System

Debian GNU/Linux 12 (bookworm), kernel 4.19.0-27-amd64, Apache + PHP-FPM

主要語言
C
星號
40.4k
分支
8.2k
平均合併
2 天 15 小時
30 天內合併 PR
113

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

php/php-src 的其他 Issue

查看 php/php-src 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。