Increase script sleep in FPM process idle test

[bukka]

No description provided.

[nikic]

Looks like it passes on azure now (including macos). There's a failure on Travis:

========DIFF========
001+ ERROR: Request failed; EXCEPTION: Read timed out
     Done
========DONE========
FAIL FPM: Process manager config pm.process_idle_timeout [sapi/fpm/tests/proc-idle-timeout.phpt]

[nikic]

Let's give it a try ... will have to keep an eye on how flaky it will be.

[bukka]

After rebasing, it still seems a bit flaky as Travis failed again for this test with

========DIFF========

001+ ERROR: Request failed; EXCEPTION: Read timed out

Will take a look a bit more into it and play with the timeout in fcgi.inc that might need increasing.

[TysonAndre]

It seems like this was merged already as 2f8407f but the test is still flaky. I see #7690 spuriously failed (it included that commit) as https://dev.azure.com/phpazuredevops/PHP/_build/results?buildId=21824&view=logs&jobId=0d3730b8-0d59-574b-ab4a-5e189a74d53b&j=0d3730b8-0d59-574b-ab4a-5e189a74d53b&t=492e5677-f211-533f-274d-3a4af39d4cce.

This test case seems to be a common cause of spurious failures? Does removing it from CI runs make sense if it times out, even with a 7 second read timeout

It looks like sapi/fpm/tests/tester.inc is trying to listen on a ipv4 TCP port on localhost. Could it be breaking if it's running in parallel with another fpm test which is already listening on the same port? (Would --CONFLICTS-- help?)

    // Each test may specify a list of conflict keys. While a test that conflicts with
    // key K is running, no other test that conflicts with K may run. Conflict keys are
    // specified either in the --CONFLICTS-- section, or CONFLICTS file inside a directory.
    $dirConflictsWith = [];
    $fileConflictsWith = [];
    $sequentialTests = [];
    foreach ($test_files as $i => $file) {
        $contents = file_get_contents($file);
        if (preg_match('/^--CONFLICTS--(.+?)^--/ms', $contents, $matches)) {

    public function getPort(string $type = 'ip', $pool = 'default', $useAsId = false)
    {
        if ($type === 'uds' && !$useAsId) {
            return -1;
        }

        if (isset($this->ports['values'][$pool])) {
            return $this->ports['values'][$pool];
        }
        $port = ($this->ports['last'] ?? 9000 + PHP_INT_SIZE - 1) + 1;
        $this->ports['values'][$pool] = $this->ports['last'] = $port;

        return $port;
    }

(Or if that isn't why, returning early if $tester->multiRequest(2, null, null, null, false, 7000); throws "Read timed out" or any Exception, since other tests should cover the ability to respond to requests to some extent)

========DIFF========
001+ ERROR: Request failed; EXCEPTION: Read timed out

[bukka]

Yes I merged it already and forgot to close this so closing now.

It's not because of conflicts because the error would be about port being already used. This timeout doesn't make much sense to me as those 7s should cover it. I will try to increase it to 10s and see if it helps. If it doesn't and I don't get another idea I will probably disable it in pipeline as the used containers are just too weak (resource limited and slow) to test all the things in FPM.

[bukka]

At the end I decided to disable the test in the pipeline as I have been playing with it locally and noticed that pm.process_idle_timeout = 1 is never actually respected by FPM and there's a further delay - it's kind of a bug in FPM which makes making the test reliable work even harder. It doesn't explain why the read takes so long in the pipeline. To find that out, I will need to add some further debugging (at least proper collecting of debug logs to start with). To sum it up I will probably need to do some extra work in FPM as well as tester to make this work more reliably.