After reset still referencing wrong files

[codedge]

Hey 👋

I am deploying my site using symlinks. So I have

/var/www/site/
 | - current -> releases/b
 | - releases
    | - a
    | - b

and have this opcache configuration.

# file /etc/php/8.4/fpm/conf.d/10-opcache.ini
opcache.preload_user=nginx
opcache.interned_strings_buffer=16
opcache.validate_timestamps=0
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0

realpath_cache_size=4096K
realpath_cache_ttl=600

# file /etc/php/8.4/fpm/conf.d/991-opcache.ini
opcache.preload = /var/www/site/releases/b/config/preload.php

After every deploy I update the value inside the file 991-opcache.ini and after that I run cachetool opcache:reset --fgi. There is no error. Also the Last restart time reflects the restart when running opcache:status.

Still, I get errors saying

Cannot redeclare class ComposerAutoloaderInitba48b4ad0d523e98af3c08be1e04ca18 (previously declared in /var/www/site/releases/a/vendor/composer/autoload_real.php:5)

which points to the older a release instead of the newer/current b release.

The only thing that helps is to restart my php8.4-fpm process.

Any idea what to do here?

[comma8600]

Does it work without the opcache.preload I saw some sort of caveat with preload that it can cause issues with namespace clashes:
see the user comments at the bottom of the config page: https://www.php.net/manual/en/opcache.configuration.php#ini.opcache.preload

tizian dot schmidlin at gmail dot com ¶
6 years ago
It should be noted that according to the original RFC (https://wiki.php.net/rfc/preload) opcache.preload caches preloaded files forever for all instances of the underlying PHP process.

That means, that hosting multiple websites on the same server might result in some unexpected behaviour.

Concrete example:

• you have a Symfony 3.2 App (which might be an endpoint of some type) and a Symfony 3.4 App (which might be your main application)
• both apps have a main Class called App that is in the same namespace (as it is usual, since the class name is unique to each project)
• depending on which app is loaded first, one or the other will work, since opcache.preload has no file based distinction of what class is used where and simply provides them to the user space

This is avoidable by simply not preloading user space classes or, if you work with FPM, by defining a pool for each app.

In order to optimize memory consumption, you might also use a common FPM Pool for all Symfony 3.4 Apps and preload the entire framework in there and simply not preload user space classes (which might be cached by opcache anyway but is slower, since it will be checked if the file has changed on every request).

[comma8600]

I can't replicate it possibly as I've not got preload working but how are you expecting the preload ini change to be picked up without a restart?

I don't see anything about cachetool opcache:reset doing more that reseting the cache nothing about getting php php-fpm to reload it's ini. I'm guessing after the clear it is then immedidately repopulated with the opcache.preload = /var/www/site/releases/a/config/preload.php then an active request will load from release/b but the autoloader will fail as many of the classes in b are already autoloaded in the preload for a.

/etc/php/8.4/fpm/conf.d/991-opcache.ini

will be read by fpm at startup or after a reload or after a kill USR2 signal (I'm trying to avoid restarts by using cachetool to clear the cache instead)

[gordalina]

@codedge can you share the output of the cachetool command with -vvv?

[comma8600]

Just hit what feels like a very similar issue on my staging, but I still cannot replicate on dev:

[Thu Sep 18 12:33:29.107560 2025] [proxy_fcgi:error] [pid 2754000:tid 140221822408256] [remote xxxxx] AH01071: Got error 'PHP message: PHP Fatal error:  Cannot redeclare composerRequire8f7ba087476ba15d0a87fd16362da979() (previously declared in /xxxxxx/old-folder/autoload_real.php:73) in /xxxxxxxx/new-folder/vendor/composer/autoload_real.php on line 73'

I canot solve it with opcache:reset nor stat:clear nor reloading the php-fpm pool with kill -USR2, nor changing the config to restore:
opcache.validate_timestamps
and or
opcache.revalidate_path

this doesn't resolve over time, so not even sure if it's either cache as both should have a ttl.

[gordalina]

This could be related to php/php-src#16668
@Seldaek is there a way to change the, I assume hash, in the function name?

[Seldaek]

If you delete vendor/autoload.php then run composer dumpautoload it'll generate a new hash based on the lock file hash. Or you can force it to a random value by setting "composer config autoload-suffix foobar" then dumpautoload again.

[comma8600]

@gordalina and @Seldaek

Thank you adding the suffix has fixed my issue, since we often deploy small changes with no composer dependency changes, I'm tweaking our deploy tool to always generate a timestamped suffix.

Am I right in thinking this is not a cachetool issue but a composer issue with how it uses opcache_compile_file()?

I still don't quite understand why the function clash is occuring when I am dump-autoloading. reloading php-fpm and clearing the opcache. I don't understand how composer is somehow compiling from the old deployment folder

[Seldaek]

Am I right in thinking this is not a cachetool issue but a composer issue with how it uses opcache_compile_file()

No, Composer does not call opcache anywhere.

I think what happens is:

• your code runs, so autoload.php is in opcache
• you deploy new code, dump a new autoload file
• the new code gets executed before opcache is cleared, and that means the file gets included again as it is a new file, but it declares the same function and that causes issues.

Also note that from what you said:

Cannot redeclare class ComposerAutoloaderInitba48b4ad0d523e98af3c08be1e04ca18 (previously declared in /var/www/site/releases/a/vendor/composer/autoload_real.php:5)
which points to the older a release instead of the newer/current b release.

the path in there is the one of previously declared location, so that makes sense that this is the old release path. It just means it is loading it before resetting opcache IMO.

IMO it is probably something due to preloading, as I have a similar deployment setup and never encountered any opcache issues.. I normally swap symlinks which doesn't really have an effect as everything is in opcache and opcache.validate_timestamps is off, then I run opcache:reset and at that point the new files get loaded.

[Seldaek]

How do you update the preload path? Do you reload/restart fpm? Could it trigger it to load the new preload file without/before opcache being cleared? If so that'd be hard to fix IMO as you'll always have a short period of time between clearing and restarting where some issues can occur. Using preloading without taking servers offline during deploy is extremely difficult.

[comma8600]

Thanks for the explaination. That was my general thinking but no amount of cache clearing or php-fpm reloads were solving the issue, the error wasn't a temporary one during the deployment but continued after. This isn't a problem with cachetool as php-fpm kill -USR2 wasn't helping either.

I've currently got that rather disconcerting feeling of having a fix but not really understanding exactly why the fix works. How the autoload class was causing redeclare errors but none of the application code which also had functions same names across deployments had redeclare errors.

How do you update the preload path? Do you reload/restart fpm? Could it trigger it to load the new preload file without/before opcache being cleared? If so that'd be hard to fix IMO as you'll always have a short period of time between clearing and restarting where some issues can occur. Using preloading without taking servers offline during deploy is extremely difficult.

Myself I'm not using the preload path for the exact reasons you state. Thankfully I don't need it. I did try and replicate it two weeks ago however while I ran a test deployment I didn't test a scenario with no composer change. Just to rule it out as a potential issue for our symlink based deployment process. To get preloads working it would probably require two php-fpm instances behind a load balancer or some sort of containerised deployment.

[gordalina]

Closing this ticket, feel free to re-open.