Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OPcache Delays Composer Updates #3460

mattstein opened this issue Nov 9, 2018 · 1 comment


None yet
2 participants
Copy link

commented Nov 9, 2018


Found jsun in Craft Slack experiencing the same problem: composer update in multiple production environments would run just fine, update the /vendor folder, and /admin/utilities/updates would still report the exact same updates (completed via composer at the command line) were still pending. This means any new/changed methods would throw errors/exceptions as well. After maybe 10-20 minutes, Craft would register the updates and all would be well.

We each verified that opcache was up and running in the affected environments (consistently true), and I tried running a script from the command line to run opcache_reset() after the composer update. A restart of PHP via service php-fpm reload immediately did the trick though; refreshing /admin/utilities/updates immediately reflected the changes.

I also found that this isn't a Craft-specific thing, as another CMS ending with "atamic" exhibited the exact same behavior in the same environment. It may just be a matter of needing to responsibly use and clear the opcache, but I'm reporting it here in case there's anything Craft can do when determining whether updates are applied.

Ruling out craft/storage/runtime/compiled_templates since that's apparently being cleared now.

Steps to reproduce

  1. Pull in a new composer.json with updated Craft and/or plugin updates.
  2. Run composer update, confirm success.
  3. Head to /admin/utilities/updates, where the new versions you just installed are still reportedly "available."
  4. Restart PHP service php-fpm reload, which is probably the neanderthal method of forcing an opcache clear.
  5. Return to /admin/utilities/updates and refresh, watching Craft acknowledge the updates from step 2.

Additional info

  • Craft version: 3.0.28-
  • PHP version: 7.2.11 (php-fpm, nginx 1.15.6)
  • Database driver & version: MariaDB 10.1.36

OPcache settings:

opcache.blacklist_filename => no value
opcache.consistency_checks => 0
opcache.dups_fix => Off
opcache.enable => On
opcache.enable_cli => Off
opcache.enable_file_override => On
opcache.error_log => no value
opcache.file_cache => no value
opcache.file_cache_consistency_checks => 1
opcache.file_cache_only => 0
opcache.file_update_protection => 2
opcache.force_restart_timeout => 180
opcache.huge_code_pages => Off
opcache.inherited_hack => On
opcache.interned_strings_buffer => 8
opcache.lockfile_path => /tmp
opcache.log_verbosity_level => 1
opcache.max_accelerated_files => 65407
opcache.max_file_size => 0
opcache.max_wasted_percentage => 5
opcache.memory_consumption => 784
opcache.opt_debug_level => 0
opcache.optimization_level => 0x7FFFBFFF
opcache.preferred_memory_model => no value
opcache.protect_memory => 0
opcache.restrict_api => no value
opcache.revalidate_freq => 180
opcache.revalidate_path => Off
opcache.save_comments => 1
opcache.use_cwd => On
opcache.validate_permission => Off
opcache.validate_root => Off
opcache.validate_timestamps => On

This comment has been minimized.

Copy link

commented Nov 12, 2018

As of tomorrow’s release, Craft will call opcache_reset() after running Composer operations. Not going to help if Craft isn’t the one running the Composer operation, though, so if that’s happening automatically as part of a deployment pipeline, you’ll need to manually reset OPcache as part of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.