WordPress.org

Make WordPress Core

Opened 6 months ago

Closed 7 weeks ago

Last modified 2 days ago

#51686 closed defect (bug) (fixed)

Not invalidating files in opcode cache after core update

Reported by: Krstarica Owned by: mikeschroder
Milestone: 5.7 Priority: normal
Severity: normal Version: 5.5
Component: Upgrade/Install Keywords: has-patch commit dev-reviewed
Focuses: Cc:

Description

Although #36455 is implemented and it properly invalidates files in Zend OpCache when doing plugin updates, it seems it does not work properly when doing core updates.

When installing the latest version of WordPress using wp-admin/update-core.php or being auto-updated, it shows like nothing has happened, meaning it is still pulling things from Zend OpCache.

Attachments (2)

51686.2.diff (1.4 KB) - added by mikeschroder 7 weeks ago.
Move one invalidation call after chmod, per @SergeyBiryukov's recommendation, and add comments.
fake_update.4.diff (3.2 KB) - added by mikeschroder 7 weeks ago.
Example of how to test this change. Includes allowing the testing of dev update-core.php rather than the update package's one.

Download all attachments as: .zip

Change History (26)

This ticket was mentioned in Slack in #hosting-community by javier. View the logs.


6 months ago

This ticket was mentioned in Slack in #core by noisysocks. View the logs.


6 months ago

#4 @mikeschroder
6 months ago

  • Keywords reporter-feedback added

Thanks for the report!

This worked for me in testing ahead of the update, so I'd love to figure out why it's not working in practice there.

Would you mind providing some details about the configuration on the site, so that I can try to reproduce?

Things like the host, PHP version, opcache configuration, and how the upgrade occurred (Was it started by core? The host? WP-CLI, etc) would be really helpful.

Thanks much!

#5 @mikeschroder
6 months ago

  • Version changed from 5.5.2 to 5.5

#6 @Krstarica
6 months ago

Thanks for getting back to me Mike.

It happens both (1) when auto-update is triggered by WordPress itself and (2) when manually click update button at wp-admin/update-core.php. The same thing occurs in all previous versions of WordPress, too. After the upgrade is finished, it again shows prompt that the new version is available. systemctl reload php-fpm doesn't fix things.

OS: CentOS Linux release 7.8.2003 (Core)

PHP 7.3.24 (cli) (built: Oct 27 2020 11:01:59) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.24, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.24, Copyright (c) 1999-2018, by Zend Technologies

OPCache configuration in php.ini:

opcache.memory_consumption=640
opcache.interned_strings_buffer=16
opcache.fast_shutdown=1
opcache.enable_cli=0
opcache.revalidate_freq = 60
opcache.max_accelerated_files=30000

This ticket was mentioned in Slack in #core-auto-updates by audrasjb. View the logs.


5 months ago

This ticket was mentioned in PR #976 on WordPress/wordpress-develop by stodorovic.


2 months ago

  • Keywords has-patch added

#9 @stodorovic
2 months ago

It looks that version.php isn't invalidated because it isn't copied until everything else is verified. The function copy_dir invalidates other files, but version.php is still cached (because it's copied later with different method) . I've created PR 976: https://github.com/WordPress/wordpress-develop/pull/976 which will invalidate version.php from OPcache.

For testing, it's enough to add following line into php.ini:

opcache.validate_timestamps = 0

#10 @mikeschroder
7 weeks ago

  • Keywords reporter-feedback removed
  • Owner set to mikeschroder
  • Status changed from new to assigned

Commented on #51281 about this, but thanks much @stodorovic for the patch!
Great catch.

I'll work on getting this in.

@mikeschroder
7 weeks ago

Move one invalidation call after chmod, per @SergeyBiryukov's recommendation, and add comments.

This ticket was mentioned in Slack in #core-auto-updates by mike. View the logs.


7 weeks ago

#12 @mikeschroder
7 weeks ago

  • Keywords needs-testing added
  • Milestone changed from Awaiting Review to 5.8

@mikeschroder
7 weeks ago

Example of how to test this change. Includes allowing the testing of dev update-core.php rather than the update package's one.

#13 @mikeschroder
7 weeks ago

This was tricky to test, so figured I'd document it here.

Assuming I haven't missed anything, this does look to solve both this problem and #51281.

This is how I ended up fixing it (from Slack):
I was able to verify this by commenting out the overwriting of src/wp-admin/includes/update-core.php within src/wp-admin/includes/class-core-upgrader.php which let the patched version run against an otherwise equal update.

I've attached the diff of the test environment for using the WordPress built-in Docker environment, in case it helps anyone in the future.

#14 @mikeschroder
7 weeks ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 50475:

Upgrade/Install: Invalidate OPcache for version.php during update.

Invalidate OPcache for wp-content/version.php on update individually, since it’s copied separately.

Props stodorovic, krstarica, cenay, desrosj, pbiron, sergeybiryukov, mikeschroder.
Fixes #51686, #51281.
See #36455.

#15 @mikeschroder
7 weeks ago

  • Keywords dev-feedback added; needs-testing removed
  • Milestone changed from 5.8 to 5.7
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for 5.7 consideration per @SergeyBiryukov.

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


7 weeks ago

#17 @SergeyBiryukov
7 weeks ago

  • Keywords commit dev-reviewed added; dev-feedback removed

[50475] looks good to backport.

#18 @mikeschroder
7 weeks ago

Thanks much! I'll take care of it.

Per our conversation in Slack, also going to add [50460], since the comments in this one were changed to match that change.

#19 follow-up: @mikeschroder
7 weeks ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 50477:

Upgrade/Install: Invalidate OPcache for version.php during update.

Invalidate OPcache for wp-content/version.php on update individually, since it's copied separately.

Props stodorovic, krstarica, cenay, desrosj, pbiron, sergeybiryukov, mikeschroder.

Reviewed by mikeschroder, SergeyBiryukov.
Merges [50460] and [50475] to the 5.7 branch.
Fixes #51686, #51281.
See #36455.

#21 in reply to: ↑ 19 @mikeschroder
6 weeks ago

Replying to mikeschroder:

In 50477:

<snip>

Invalidate OPcache for wp-content/version.php on update individually, since it's copied separately.

A quick note, pointed out by @stodorovic, that this should say wp-includes/version.php.
It was a mistake in the commit message, but the path is correct in the committed code.

Sorry about that, and thanks again!

#22 @Krstarica
2 days ago

Just experiencing the same issue after got email notification that WordPress was auto-updated to 5.7.1.

/wp-admin/update-core.php shows Current version: 5.7.1 and You have the latest version of WordPress.

On all other admin pages there is a notice WordPress 5.7.1 is available! Please update now.

/wp-includes/version.php contains $wp_version = '5.7.1';

It's the same even after systemctl reload php-fpm which supposed to clear opcache. Even systemctl restart php-fpm didn't help.

#23 @stodorovic
2 days ago

@Krstarica It works for me. I didn't see same issue after automatic updates (5.7 -> 5.7.1). Did you set opcache.restrict_api or opcache.file_cache? Did you try to run wp core version?

There is cli utility - https://github.com/gordalina/cachetool which can help to you see more details about OPcache.

PS: It's possible that admin pages are somehow cached by NGinx FastCGI cache. Did you try to clear this cache?

Last edited 2 days ago by stodorovic (previous) (diff)

#24 @Krstarica
2 days ago

opcache.restrict_api => no value => no value
opcache.file_cache => no value => no value

No change after systemctl restart nginx

I am confused that update-core.php shows WordPress is up-to-date, but still seeing notice to update it. Does it pull such information from database?

BTW, I opened #53039 because this ticket is closed.

Note: See TracTickets for help on using tickets.