Context
A deployment copies new PHP files successfully, but some users still see earlier behavior. OPcache stores compiled scripts for the PHP runtime, so the release must define when that runtime recognizes changed code. The relevant cache is the one serving web requests, which may differ from a command-line PHP process.
Prepare the deployment method, PHP/FPM version, pool and instance inventory. Identify whether releases replace files in place or switch a versioned directory. Use a harmless build identifier for diagnostics and avoid publishing a general phpinfo() page; it can expose sensitive configuration and infrastructure details.
Inspect the web runtime
- Confirm which PHP runtime serves the affected request. Map the web server's FastCGI destination to the FPM pool or equivalent handler, then identify every application node.
php --inireports the CLI configuration and is not proof of the web pool's settings. A private application diagnostic can expose selected safe values and a build identifier without dumping the whole runtime environment. - Review effective
opcache.validate_timestampsandopcache.revalidate_freqin that runtime. PHP documents that the frequency is ignored when timestamp validation is disabled. Other related settings and path behavior can affect a versioned-release deployment, so compare the current procedure with the exact PHP release's manual rather than assuming a file copy is sufficient activation. - Inspect the deployment's invalidation or process-lifecycle step. Determine whether it reaches the actual web runtime and every node. Running an OPcache reset in a separate CLI process does not demonstrate that the FPM workers serving requests changed state. Also review whether long-lived workers or application-level caches retain release-specific objects independently of compiled scripts.
- Query a restricted build marker repeatedly through the real request path. Record node identity safely where appropriate. A load balancer can alternate between current and stale instances, creating an intermittent symptom. Compare direct approved node checks with the public route instead of relying on one successful request.
An illustrative half-activated release
In an illustrative two-node PHP service, deployment invalidates the cache on only one node. Tests hit the updated node, while later users reach the other. The files on both disks are current, but activation evidence differs. The release procedure needs node-by-node completion and an end-to-end marker check rather than another file synchronization.
| Observation | Check | Likely boundary |
|---|---|---|
| CLI sees new settings, web does not | Runtime-specific configuration | Different SAPI or pool |
| Alternating build identifiers | Node inventory and load-balancer path | Partial activation |
| Files current, behavior stale | Timestamp policy and invalidation | Compiled-code lifecycle |
| Build current, data view stale | Application cache and state | Separate caching layer |
Correct and verify the release contract
Choose a supported strategy: timestamp checking with understood behavior, or explicit controlled invalidation/restart tied to immutable releases. Preserve the previous release and rollback procedure. Do not expose a public reset endpoint to make deployment convenient; activation is an administrative capability.
Verify current code on every node, then through the load-balanced application workflow. Check error logs during activation and validate a rollback rehearsal in staging. A build marker proves code identity for that path; it does not replace functional acceptance of changed business behavior.
Maintain deployment evidence
Record PHP versions, pools, OPcache policy and activation ownership with the release SOP. Monitor mixed build identifiers and failed activation steps. Revalidate the procedure after changing pool topology or deployment paths. Clouvenix Linux administration can help connect runtime configuration with dependable releases.