As shown by this job output Process::stop() does not stop a PHP web server process (php -S).

The following command output shows the web server process, started by Process during the test run, is still running even after the test suite has completely finished.

$ ps auxw | grep php
travis 4049 0.0 0.0 254180 15024 pts/1 S+ 10:19 0:00 php -S localhost:12345 feedback.php

Process::getStatus() mistakenly reports terminated immediately after the Process::stop() call indicating Process earnestly believes the process has been successfully stopped when, in fact, it is still running.

As an aside, these tests do pass on Ubuntu 14.04 and Windows 7. Only 12.02 (Travis) is affected.

EDIT: Further debugging reveals Process may possess an incorrect PID for the web server. The test script outputs the following.

Killing 4049...
Killing 4051...
$ ps auxw | grep php
travis     4050  0.2  0.0 254180 15032 pts/1    S+   12:44   0:00 php -S localhost:12345 feedback.php

That is, it kills PIDs 4049 and 4051 but 4050 is still running the server.

EDIT2: I was able to get the tests to pass by running posix_kill($process->getPid() + 1, SIGINT); instead of $process->stop(0, SIGINT);. This proves the PID value held by Process is one less than it should be. Maybe this has something to do with container-based environments? This modification makes Travis pass but every other normal environment fails.

In case you want to try to reproduce this, the specific container Travis uses can be fetched with docker pull quay.io/travisci/travis-php. This seems like it might be a bug in proc_get_status or even Docker.

EDIT3: This is happening because, on some systems, the process is launched in a shell wrapper (sh -c) whilst on others it is not. However, it remains entirely unclear what determines whether it is launched with a shell wrapper, how to determine if a shell wrapper has been used, and how to reliably get the child PID. All of these problems make the Process component quite unpredictable and less useful.