Run tests on php-fpm

In general this seems to be a problem with fpm/fastcgi_finish_request() and code running after that call.
This has been introduced in https://github.com/symfony/symfony/pull/1262 and reported as problem on http://stackoverflow.com/questions/14191947/php-fpm-fastcgi-finish-reque... and more important on https://github.com/symfony/symfony/issues/6417

Since this blocks PHP 5.4 testing, and I don't really want to release without 8.x automatically tested on 5.4, bumping to critical.

#2157053: Ensure register_shutdown_function() works with php-fpm (blocks testbot php-fpm)

#2157053: Ensure register_shutdown_function() works with php-fpm (blocks testbot php-fpm) was about the way we were testing shutdown functions. I'm pretty sure this will still be a problem. Reading https://github.com/symfony/symfony/issues/6417

Not sure what we can do here :( Perhaps a very high priority terminate event listener to write the session?

I'm pretty sure this will still be a problem.

D8 is green on PHP 5.4 now:

https://qa.drupal.org/pifr/test/600303#tabset-tab-4

So unless that test result is not using php-fpm, we should be fine?

Just building a php-fpm environment... but I see no reason why our solution to #2157053: Ensure register_shutdown_function() works with php-fpm (blocks testbot php-fpm) would have solved this issue.

Pretty sure the patch in #2157053: Ensure register_shutdown_function() works with php-fpm (blocks testbot php-fpm) changed nothing for this issue. I don't think they're directly related to session handling either ; more probably they're related to a few race conditions just like the one that needed to be dealt with in #2157053: Ensure register_shutdown_function() works with php-fpm (blocks testbot php-fpm), checking the state of the system right after the request handed when there's still some processing going on ; that would explain why the test sometimes pass, sometimes doesn't pass. I can get the "Value NULL is TRUE" fail to reliably disappear using the attached test patch.

Locally, the test trying to use the full range of alias character is failing, and it does fail when using the UI too… Not completely sure what to do about that, I think it's related to server configuration. The unicode characters work fine, the special ASCII characters and the characters looking like a percent-espaced string don't.

Let's add another datapoint that makes me thinks there might in fact something really strange with our url generation handling:

- Install a standard D8 site
- Create a new node, enter a?b as a url path alias
- You're redirect to a?b, which tries to load page a giving it query string b on FPM, which means you get a page not found. I guess it somehow works in mod_apache due to the two rewrite

And then for the really weird part
- Go to admin/config/search/path
- Click on the a?b alias
- At that point you're *correctly* redirected to a%3Fb, and you can thus access the node.

Another update that will hopefully save some time for others looking into this ; alias with a ? in them are correctly dealt with when the url is generated through UrlGenerator::generateFromPath, but fails when it's generated through UrlGenerator::generateFromRoute. That's why the test and pretty much every thing linking to the node (like the homepage teaser list) is failing, but the path admin overview work.

D8 is green on PHP 5.4 now:

https://qa.drupal.org/pifr/test/600303#tabset-tab-4

So unless that test result is not using php-fpm, we should be fine?

It does not. We have reserved test servers for 5.4 and 5.5 tests right now, see the testbot list.

Wondering how those aliases could work with PHP working as a module, I've made a few more investigations leading to... interesting findings. I would be grateful if anyone could confirm. In short: even though the Path alias functionnality is passing, in fact, trying to use either "a?b" or "- ._~!$'\"()*@[]?&+%#,;=:%23%25%26%2B%2F%3Féøïвβ中國書۞" in fact make the links not working, everything leading to page not found errors (The requested page "/a" could not be found)

Not sure why the test is passing ; I suspect Simpletest is somehow rewriting / encoding the URL, leading to a falsely passing test. Not sure either why this is not falsely passing in FPM yet.

@DeFr: I'm able to confirm your observations regarding PathAliasTest — those assertions also do not pass for me when I run that test locally. I always assumed that it might be an issue with Apache 2.4, PHP 5.4, or something else in my local (Windows) environment... We should fix that test in a separate issue.

     $this->drupalPostForm('admin/config/search/path/add', $edit, t('Save'));
+    sleep(1);

So this is essentially the same fix as in #2194357: CacheArray::__destruct() invoked after test tables have been removed — the only difference is that it is applied after an (arbitrary) POST request.

I really wonder whether we shouldn't move the fix from #2194357 into the central HTTP request handling method WebTestBase::curlExec()?

50ms extra on every HTTP request to ensure that shutdown functions have run isn't the end of the world? You need to perform 20 requests to get a delay of 1s.

Discussed with @catch, @alexpott, @webchick, and @Dries. As far as we know this no longer is a blocker for testbot (which is already testing on 5.4), but would impact sites using php-fpm. Downgrading to major.

Can someone familiar with php-fpm check whether this issue still exists now that we are on 5.5?

I checked this on 5.6 with fpm, and it still fails.

@jhedstrom Thank you for testing.

I am not sure how run-tests.sh is related to php-fpm? This script runs PHP in CLI mode, not in FPM mode.

To test is the issue exists, I have set up 2 web servers (using Debian 8.1 as a base system):

Apache 2.4 + PHP 5.6 built as a module (runs on port 80)
nginx 1.6.2 using PHP 5.6 as FPM gateway (runs on port 8080, FPM service uses unix socket)

Apache and nginx share exactly the same Drupal installation, all Path tests pass

as an additional check, I've run
php core/scripts/run-tests.sh Path
this one passes too

As part of the Bug Smash Initiative I triaged this issue that hasn't been updated in 4 years.

Our testing infrastructure has changed dramatically since then.

I've pinged @xjm and @catch as to whether we can close this now.

@xjm mentioned discussing with @mixologic, I will endeavour to do so.

Discussed with @mixologic and he agreed that this is postponed on having fpm testing, which is #2949210: Drupalci Roadmap

So postponing on that and repurposing as a task to add fpm testing.

Triaging for Bug Smash Initiative.

Switching to PMNMI as I don't see fpm mentioned in #2949210: Drupalci Roadmap.

Discussed with @mixologic in Slack and this is still postponed but on the GitLab Acceleration project:

https://www.drupal.org/drupalorg/roadmap/gitlab-acceleration

#3227737: [Meta] GitLab Acceleration Initiative