OPcache Delays Composer Updates

[mattstein]

Description

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-3.0.30.2
• 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

[brandonkelly]

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.