WordPress.org

Make WordPress Core

Opened 13 months ago

Closed 9 months ago

Last modified 8 months 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 9 months ago.
Move one invalidation call after chmod, per @SergeyBiryukov's recommendation, and add comments.
fake_update.4.diff (3.2 KB) - added by mikeschroder 9 months 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.


13 months ago

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


13 months ago

#4 @mikeschroder
13 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
13 months ago

  • Version changed from 5.5.2 to 5.5

#6 @Krstarica
13 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.


13 months ago

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


10 months ago

  • Keywords has-patch added

#9 @stodorovic
10 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
9 months 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
9 months 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.


9 months ago

#12 @mikeschroder
9 months ago

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

@mikeschroder
9 months 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
9 months 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
9 months 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
9 months 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.


9 months ago

#17 @SergeyBiryukov
9 months ago

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

[50475] looks good to backport.

#18 @mikeschroder
9 months 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
9 months 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
9 months 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
8 months 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
8 months 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 8 months ago by stodorovic (previous) (diff)

#24 @Krstarica
8 months 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.