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
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 48/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Bereich
- backend, operating-systems
Rechercherichtung
Beginnen Sie damit, die HTTP-Anfrage in einem langlebigen PHP-FPM worker mit aktiviertem open_basedir zu reproduzieren, und folgen Sie dabei der im Bericht beschriebenen file_exists(), clearstatcache(), unlink(), stat(), realpath(), fopen() und scandir()-Sequenz. Vergleichen Sie PHP 8.5.2 mit 8.4.17 und bestätigen Sie, dass der Fix dafür sorgt, dass file_exists() nach dem Löschen false zurückgibt, ohne dass der worker beendet werden muss.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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/mntidentical), docroot on a local ext4 mount. From the shell,os.access(path, F_OK)andos.path.exists(path)both returnFalse. - OPcache disabled.
- Custom stream wrappers /
auto_prepend_file: only built-in wrappers registered,stream_wrapper_restore('file')changes nothing,auto_prepend_fileempty. - Realpath cache TTL: state persists far beyond
realpath_cache_ttl=120with 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_basedirset for the pool (docroot, session and tmp dirs,/tmp:/usr/bin)realpath_cache_ttl=120disable_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
- Vorherrschende Sprache
- C
- Sterne
- 40.4k
- Forks
- 8.2k
- Ø Merge
- 2 T. 17 Std.
- Gemergte PRs (30 T.)
- 115
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus php/php-src
-
Bug Status: Needs Triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
-
Bug Status: Needs Triage
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
-
Bug Status: Needs Triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
-
Flaky hrtime.phpt test OffenBug Category: Tests Status: Verified
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
-
Bug SAPI: fpm Status: Needs Triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
Ähnliche Issues
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
bradcypert/plum#53 ·
-
Component: GLib
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Status: Opened
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
nextbsd/nextbsd-userland#285 ·