Problem/Motivation

Two systems, both PHP 5.5.3, with Opcode cache enabled, can't see any obvious different settings.

Running tests on one of them works fine, fails on the other, because the repeated require of test settings.php is cached and reads an old version without config directories.

Proposed resolution

I can fix it by adding

opcache_invalidate(DRUPAL_ROOT . '/' . $conf_path . '/settings.php', TRUE);

call in drupal_settings_initialize() force the invalidation, but that doesn't make much sense and we want to avoid it on actual sites, obviously.

Adding a (global) opcache_reset() in WebTestBase::setUp() works, too.

clearstatcache() did not help.

CommentFileSizeAuthor
#6 drupal8.opcache.6.patch981 bytessun
#1 remove-reload-settings-2194071-1.patch604 bytesBerdir
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir commented
Status: Active » Needs review
FileSize
remove-reload-settings-2194071-1.patch604 bytes

What does seem to work for me is to remove that call.

Status: Needs review » Needs work

The last submitted patch, 1: remove-reload-settings-2194071-1.patch, failed testing.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Title: Issues when running tests with PHP 5.5 and opcache enabled » WebTestBase::setUp() fails with PHP 5.5 and enabled opcache
Issue tags: +PHP 5.5

Adjusting the issue title a little bit; I'm consistently mistaking this browser tab as the core "Issues" tab. ;)

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir commented
Status: Needs work » Needs review

1: remove-reload-settings-2194071-1.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 1: remove-reload-settings-2194071-1.patch, failed testing.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
FileSize
drupal8.opcache.6.patch981 bytes

Now, that test failure is essentially the expected failure and the reason for why I added that call to drupal_settings_initialize():

The idea was to guarantee that the test operates on the actual information in settings.php, and not just some global state and global variables that just coincidentally might happen to have the same or similar information as settings.php.

Point in case here:

  1. WebTestBase::setUp() writes $settings['simpletest_parent_profile'] into settings.php, before executing the installer.
  2. The installer rewrites settings.php, instantiates a new Settings, and generally futzes with global state in many ways.
  3. The call into drupal_settings_initialize() ensures that all global state/variables that are solely controlled by settings.php will actually represent the actually contained values for Settings + global $base_url, $databases, $cookie_domain, $drupal_hash_salt, $config_directories, $config;
  4. By removing this call/refresh, the environment of the test runner is different to the environment of the test child site.

Due to that, I would actually prefer to put something along the lines of this into WebTestBase::setUp():

if (function_exists('opcache_invalidate')) {
  opcache_invalidate(DRUPAL_ROOT . '/' . $conf_path . '/settings.php', TRUE);
}
drupal_settings_initialize();

That said, I wonder whether this refresh doesn't actually belong into drupal_rewrite_settings(), because that is where the PHP file gets actually rewritten?

Let me actually attach that as a patch. Can you try it out? (I didn't upgrade yet)

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Issue summary: View changes
Status: Needs work » Needs review

That said, you mentioned that you're able to reproduce this on one of your two PHP 5.5 boxes only?

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir commented
Priority: Normal » Critical

Nope, on both on the next day, I guess I was just too stupid to do a git pull :)

Anyway, just had a confirmation that I'm not the only one seeing this, so raising to critical.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

@berdir would you mind checking the value of opcache.validate_timestamps?

mikeytown2’s picture

mikeytown2 CreditAttribution: mikeytown2 commented
Status: Needs review » Closed (duplicate)

This seems to be a duplicate of #779482: Installation failure when opcode cache is enabled
Linked issue tries to fixes it for other opcode caches as well.