Skip to content

[WebServer] server:start failed (OSX, php 7.3.2) #30471

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
Plopix opened this issue Mar 7, 2019 · 9 comments
Closed

[WebServer] server:start failed (OSX, php 7.3.2) #30471

Plopix opened this issue Mar 7, 2019 · 9 comments

Comments

@Plopix
Copy link
Contributor

Plopix commented Mar 7, 2019

Symfony version(s) affected: v4.2.3
PHP version: PHP 7.3.2 on OS X installed with Brew. (pcntl present)

Description

bin/console server:start 127.0.0.1:1664

=> does not start anything on PHP 7.3 (on 7.2 it is working as expected)

  • server:start is working.
  • I debugged and when I remove the fork that is working too.

How to reproduce

composer create-project symfony/website-skeleton my_project
cd my_project
composer require server --dev
bin/console server:start 127.0.0.1:1664

Then netstat -an | grep LISTEN | grep 1664 and you will see nothing.

As soon as I switch to PHP 7.2.15, it is working again.

Additional context

I have tried to debug, using "file_put_contents" in the child (after fork).
The further I can go is in createServerProcess
This is going to be weird:

        file_put_contents("/tmp/plop", "--".PHP_EOL, FILE_APPEND);
        file_put_contents("/tmp/plop", "Before PhpExecutableFinder - ".__LINE__.PHP_EOL, FILE_APPEND);
        $finder = new PhpExecutableFinder();
        file_put_contents("/tmp/plop", "After PhpExecutableFinder - ".__LINE__.PHP_EOL, FILE_APPEND);

Result is:

--
Before PhpExecutableFinder - 149

Even weirder, if I add debug in PhpExecutableFinder constructor

    public function __construct()
    {
        file_put_contents("/tmp/plop", "Before new ExecutableFinder(); - ".__LINE__.PHP_EOL, FILE_APPEND);
        $this->executableFinder = new ExecutableFinder();
        file_put_contents("/tmp/plop", "Before new ExecutableFinder(); - ".__LINE__.PHP_EOL, FILE_APPEND);
    }

The result is THE SAME, which does not make any sense to me:

--
Before PhpExecutableFinder - 149

So I pushed the debug, trying weird things, I have removed all the comments in PhpExecutableFinder.php and magically it progressed

--
Before PhpExecutableFinder - 149
Before new ExecutableFinder(); - 9

I did the same for ExecutableFinder.php

--
Before PhpExecutableFinder - 149
Before new ExecutableFinder(); - 9
After new ExecutableFinder(); - 11
After PhpExecutableFinder - 151

But the command is still now working, the new Process is failing

    private function createServerProcess(WebServerConfig $config)
    {
        file_put_contents("/tmp/plop", "--".PHP_EOL, FILE_APPEND);
        file_put_contents("/tmp/plop", "Before PhpExecutableFinder - ".__LINE__.PHP_EOL, FILE_APPEND);
        $finder = new PhpExecutableFinder();
        file_put_contents("/tmp/plop", "After PhpExecutableFinder - ".__LINE__.PHP_EOL, FILE_APPEND);
        if (false === $binary = $finder->find(false)) {
            throw new \RuntimeException('Unable to find the PHP binary.');
        }

        $xdebugArgs = ini_get('xdebug.profiler_enable_trigger') ? ['-dxdebug.profiler_enable_trigger=1'] : [];

        file_put_contents("/tmp/plop", var_export($xdebugArgs, true).PHP_EOL, FILE_APPEND);
        file_put_contents("/tmp/plop", var_export($finder->findArguments(), true).PHP_EOL, FILE_APPEND);

        file_put_contents("/tmp/plop", var_export($config->getAddress(), true).PHP_EOL, FILE_APPEND);
        file_put_contents("/tmp/plop", var_export($config->getRouter(), true).PHP_EOL, FILE_APPEND);

        $process = new Process(array_merge([$binary], $finder->findArguments(), $xdebugArgs, ['-dvariables_order=EGPCS', '-S', $config->getAddress(), $config->getRouter()]));

        file_put_contents("/tmp/plop", "PROCESS CONSTRUCTED".PHP_EOL, FILE_APPEND);
...

So I continued, it does not enter into the constructor at all. So I removed all the comment of Process.php, and I went further... and further removing those comments from files:

  • PipesInterface
  • AbstractPipes
  • UnixPipes
  • Process

And it finally worked ... but I am lost... I think that is a PHP bug.
I tried removing OPcache, but no change.

I then tried on Docker

docker run -it --rm php:7.3.2 /bin/bash
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === '48e3236262b34d30969dca3c37281b3b4bbe3221bda826ac6a9a62d6444cdb0dcd0615698a5cbe587c3f0fe57a54d8f5') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"
mv composer.phar composer
apt-get update
apt-get install git zlib1g-dev
docker-php-ext-install zip pcntl
docker-php-ext-enable pcntl
./composer create-project symfony/website-skeleton my_project
cd my_project
../composer require server --dev
bin/console server:start 127.0.0.1:1664

=> IT WORKS.. so definitely something on Mac OS X, or PHP Brew...

Does someone reproduce this?
@kix
Copy link
Contributor

kix commented Mar 7, 2019

This is due to a bug introduced in newer PHP builds on Homebrew. See:
#30328
bobthecow/psysh#540 (comment)
Homebrew/homebrew-core#35491

@fabpot
Copy link
Member

fabpot commented Mar 7, 2019

Let's close then.

@fabpot fabpot closed this as completed Mar 7, 2019
@Plopix
Copy link
Contributor Author

Plopix commented Mar 7, 2019

thx @kix, I still don't get why it worked when I removed those comments but who cares, that will be fixed at some point ;) symfony local:server:start works much better anyway ;-)

@Plopix
Copy link
Contributor Author

Plopix commented Mar 8, 2019

FYI: 7.3.3 does not fix the issue.

@andreybolonin
Copy link
Contributor

+1 sever:start is not working on php 7.3.3 macos

@krzysostry
Copy link

+1 server:start still not working on brew php 7.3.4 macOs (built: Apr 19 2019 00:20:56)

@nicodemuz
Copy link
Contributor

Still an issue on the following version:
PHP 7.3.5 (cli) (built: May 2 2019 12:40:36) ( NTS )

@fabpot
Copy link
Member

fabpot commented May 12, 2019

I would recommend people to use the Symfony CLI instead: https://symfony.com/doc/current/setup/symfony_server.html

@nicodemuz
Copy link
Contributor

Symfony CLI works well on 7.3.5! 👍

@fabpot fabpot mentioned this issue May 13, 2019
Merged
javiereguiluz added a commit to symfony/symfony-docs that referenced this issue May 17, 2019
@javiereguiluz
minor #11567 Replace the PHP built-in server with the Symfony CLI one…
c2247ed 
… (fabpot)

This PR was merged into the 3.4 branch.

Discussion
----------

Replace the PHP built-in server with the Symfony CLI one

<!--

If your pull request fixes a BUG, use the oldest maintained branch that contains
the bug (see https://symfony.com/roadmap for the list of maintained branches).

If your pull request documents a NEW FEATURE, use the same Symfony branch where
the feature was introduced (and `master` for features of unreleased versions).

-->

I think it makes sense as the built-in web server has many limitations, but also because it seems to not work on PHP 7.3 (see symfony/symfony#30471).

Commits
-------

473e072 replaced PHP built-in server with the Symfony CLI one
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@fabpot @Plopix @kix @nicodemuz @andreybolonin @krzysostry