This problem also exists on Linux Mint (which is unsurprising as it is built on top of Ubuntu).

The problem can be alleviated by running a separate instance of ChromeDriver in a second terminal window and supplying a valid port number (I used chromedriver --port 8888) and then modifying DuskTestCase with:

RemoteWebDriver::create(
    'http://localhost:8888', DesiredCapabilities::chrome()
);

(Thanks to @abalozz)

Whilst this is ok as a work around it removes one of Dusk's most appealing features (ie. not having to run a separate selenium server in order to run tests).

I initially assumed that this must be a port conflict with the default (9515) and so tried changing the port without running the separate instance of ChromeDriver but this returns a different error (saying that ChromeDriver can't be opened on that port).

simonhunt on 15 Jan 2017

👍9 😄2

I have made it work in Linux Mint installing xvfb

apt install xvfb

and changing the command in the SupportsChrome trait

static::$chromeProcess = new Process('xvfb-run ./chromedriver-linux', realpath(__DIR__.'/../bin'), null, null, null);

but not always works. Sometimes breaks with a similar error:

$ php artisan dusk
PHPUnit 5.7.5 by Sebastian Bergmann and contributors.

E.                                                                  2 / 2 (100%)

Time: 56.54 seconds, Memory: 8.00MB

There was 1 error:

1) Tests\Browser\ExampleTest::testBasicExample
Facebook\WebDriver\Exception\WebDriverCurlException: Curl error thrown for http POST to /session/fd60362a2b4df6b6d4ee9e3e9d05851d/url with params: {"url":"http:\/\/probando-dusk.dev\/"}

Operation timed out after 30001 milliseconds with 0 bytes received

and sometimes tests are very slow:

$ php artisan dusk
PHPUnit 5.7.5 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 1.02 seconds, Memory: 8.00MB

OK (2 tests, 3 assertions)

$ php artisan dusk
PHPUnit 5.7.5 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 31.41 seconds, Memory: 8.00MB

OK (2 tests, 3 assertions)

The same tests, first time run in 1 second. Second time in 31 seconds.

abalozz on 15 Jan 2017

I tried the solution of @simonhunt and it worked perfectly .
the chromedriver packaged with laravel/dusk still not working .

babanesma on 16 Jan 2017

This is resolved with PR #33 and should be closed

trideout on 18 Jan 2017

Apparently works perfectly. Thanks @trideout !

abalozz on 18 Jan 2017

@babanesma @simonhunt @abalozz, as you've been trying out Dusk on Linux, can you please check if this PR breaks your code? Here's the changed code.

Thanks.

KKSzymanowski on 20 Jan 2017

Running this (with PR #33 included) from within the Homestead vm (vagrant ssh) still gives me

`1) Tests\Browser\ExampleTest::testBasicExample
Facebook\WebDriver\Exception\WebDriverCurlException: Curl error thrown for http POST to /session with params: {"desiredCapabilities":{"browserName":"chrome","platform":"ANY"}}

Failed to connect to localhost port 9515: Connection refused`

Running it from the host takes ~13 seconds every single time. Anybody has an idea what this could cause?

mrdevries on 21 Jan 2017

👍7

updating to the latest version made tests working on ubuntu 16.04
also for @KKSzymanowski I tried your pull request on my ubuntu 16.04 and it worked

babanesma on 22 Jan 2017

@babanesma Thanks.

KKSzymanowski on 22 Jan 2017

Still having the same issue as @mrdevries in Homestead 1.0.1 on MacOS 10.12.2.

1) Tests\Browser\ExampleTest::testBasicExample
Facebook\WebDriver\Exception\WebDriverCurlException: Curl error thrown for http POST to /session with params: {"desiredCapabilities":{"browserName":"chrome","platform":"ANY"}}

Failed to connect to localhost port 9515: Connection refused

@mrdevries did you get yours to work?

zgosalvez on 25 Jan 2017

@zgosalvez from within Homestead I have the same error (but I guess that's expected because Homestead is headless and it actually starts a browser process that isn't, but I don't have experience with this so correct me if I'm wrong).

When I run artisan dusk from the host it works, but the DuskTestCase always takes 13 seconds.

mrdevries on 25 Jan 2017

@mrdevries Works fine on my host too, but I'm not experiencing much lag, might be a hardware thing. There should be a note in the docs that Dusk isn't compatible with Homestead.

All of my previous tests are now failing and impossible to run on my Homestead and continous-integration servers. Good thing there's the new laravel/browser-kit-testing package, which supports the my tests. Learn more here: https://laravel.com/docs/5.4/upgrade#upgrade-5.4.0

zgosalvez on 25 Jan 2017

😕1

Having same issue within Homestead. 10.12.2 running on MacOs Sierrra v10.12.2

**1) Tests\Feature\ViewProductListingTest::user_can_view_product_listing
Facebook\WebDriver\Exception\WebDriverCurlException: Curl error thrown for http POST to /session with params: {"desiredCapabilities":{"browserName":"chrome","platform":"ANY"}}

Failed to connect to localhost port 9515: Connection refused**

Has anybody had any luck getting around this?

nickpoulos on 27 Jan 2017

Same issue here, running Homstead v3.0.2 on Windows 10. Upgraded from Laravel 5.3 to 5.4.

Below full stack trace after running php artisan dusk.

    PHPUnit 5.7.9 by Sebastian Bergmann and contributors.

    E                                                                   1 / 1 (100%)

    Time: 1.45 seconds, Memory: 10.00MB

    There was 1 error:

    1) Tests\Browser\ExampleTest::testBasicExample
    Facebook\WebDriver\Exception\WebDriverCurlException: Curl error thrown for http POST to /session with params: {"desiredCapabilities":{"browserName":"chrome","platform":"ANY"}}

    Failed to connect to localhost port 9515: Connection refused

    /home/vagrant/Code/Laravel/vendor/facebook/webdriver/lib/Remote/HttpCommandExecutor.php:287
    /home/vagrant/Code/Laravel/vendor/facebook/webdriver/lib/Remote/RemoteWebDriver.php:121
    /home/vagrant/Code/Laravel/tests/DuskTestCase.php:32
    /home/vagrant/Code/Laravel/vendor/laravel/dusk/src/TestCase.php:180
    /home/vagrant/Code/Laravel/vendor/laravel/framework/src/Illuminate/Support/helpers.php:639
    /home/vagrant/Code/Laravel/vendor/laravel/dusk/src/TestCase.php:181
    /home/vagrant/Code/Laravel/vendor/laravel/dusk/src/TestCase.php:111
    /home/vagrant/Code/Laravel/vendor/laravel/dusk/src/TestCase.php:85
    /home/vagrant/Code/Laravel/tests/Browser/ExampleTest.php:20

    ERRORS!
    Tests: 1, Assertions: 0, Errors: 1.

BondITSolutions on 31 Jan 2017

Having the same connection issue. I use a Cent OS box (no Vagrant) as a Guest of a Windows 10 Host. Seeing through the comments, I wanted to ask: Can a headless box (no-gui installation of Linux) run Laravel Dusk normally?

Any suggestion on how to get rid of the connection refusal problem?

Why is this issue closed if a lot of people is facing the same problem?

deleugpn on 9 Feb 2017

My 2 cents here. I tried the followings and it seems that it is a step closer to running successfully. Yes, it is still not working in my machine. But perhaps it can run on yours.

I tried to execute chromedriver-linux directly, which tells me something like "libnss3.so" is missing. So I run "apt-get install libnss3". Then it tells me "error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory". I install "apt-get install libgconf-2-4" as well.

At this point, I can finally run the chromedriver-linux directly. Then I kill the shit that is using port 9515. (That shit is probably the chromedriver-linux.)

I run "php artisan dusk" again. Now it shows this error.

There was 1 error:

1) Tests\Browser\BackendLoginTest::testLoginPage
Facebook\WebDriver\Exception\UnknownServerException: unknown error: cannot find Chrome binary
(Driver info: chromedriver=2.25.426924 (649f9b868f6783ec9de71c123212b908bf3b232e),platform=Linux 4.4.0-31-generic x86_64)

[PROJECT_PATH]/vendor/facebook/webdriver/lib/Exception/WebDriverException.php:114
[PROJECT_PATH]/vendor/facebook/webdriver/lib/Remote/HttpCommandExecutor.php:322
[PROJECT_PATH]/vendor/facebook/webdriver/lib/Remote/RemoteWebDriver.php:121
[PROJECT_PATH]/tests/DuskTestCase.php:33
[PROJECT_PATH]/vendor/laravel/dusk/src/TestCase.php:180
[PROJECT_PATH]/vendor/laravel/framework/src/Illuminate/Support/helpers.php:639
[PROJECT_PATH]/vendor/laravel/dusk/src/TestCase.php:181
[PROJECT_PATH]/vendor/laravel/dusk/src/TestCase.php:111
[PROJECT_PATH]/vendor/laravel/dusk/src/TestCase.php:85
[PROJECT_PATH]/tests/Browser/BackendLoginTest.php:16

Time to sleep now. Hope that someone continue figuring out what is going on :)

P.S. I am running it in Ubuntu 14.04 Server.

alex621 on 11 Feb 2017

👍2

I've faced that problem before. You can just install Google Chrome and add the folder to your path variable (environment) and you'll probably get to where I am now (timeout). In my case it was /usr/lib64/chromium-browser/ folder.

deleugpn on 11 Feb 2017

I was stuck with this WebDriverCurlException, but it turned out that actual problem was #81
Maybe helps someone.

liepumartins on 15 Feb 2017

I'll second that, check out #81 . When I changed file permissions on the chromedriver executables, I was able to finally run Dusk.

browner12 on 15 Feb 2017

It seems like my problem was just Cent OS. I installed a new VM with Ubuntu 16.04 and shared the same folder from Windows with both instances and the Ubuntu one is capable of running the tests just fine.

deleugpn on 15 Feb 2017

All - if you are still experiencing this problem when using Homestead (as I was) - changing two lines in the SupportsChrome.php file worked.
See #71

mattkoch614 on 20 Feb 2017

Still doesn't work in Docker.

Operation timed out after 30000 milliseconds with 0 bytes received

matrunchyk on 28 Feb 2017

@matrunchyk correct me if I'm wrong, but Docker would be running on a host system, right? If that's a RedHat distribution, it won't work.

deleugpn on 28 Feb 2017

@deleugpn It's Ubuntu. Bitbucket pipelines use Docker, that's why it's important to make it working in Docker container. No luck so far.

matrunchyk on 28 Feb 2017

Have you seen my recent comment on Docker in the other issue? https://github.com/laravel/dusk/issues/71#issuecomment-282838028

SebastianS90 on 28 Feb 2017

Well, as I just discovered, it's not related to Dusk at all.
I bypassed Dusk and tried to run all these commands manually:

/usr/bin/Xvfb :17 -screen 0 1280x720x24 &
DISPLAY=:17 vendor/laravel/dusk/bin/chromedriver-linux --verbose --log-path=driver.log &
vendor/bin/phpunit -c phpunit.dusk.xml --debug -v

PHPUnit 5.7.14 by Sebastian Bergmann and contributors.

Runtime: PHP 7.0.15-0ubuntu0.16.04.2
Configuration: /var/www/html/phpunit.dusk.xml

Starting test 'Tests\Feature\ExampleTest::testBasicTest'.
.
Starting test 'Tests\Unit\ExampleTest::testBasicTest'.
.
Starting test 'Tests\Browser\ExampleTest::testBasicExample'.

............ 2 minutes LATER ..............

Facebook\WebDriver\ExceptionWebDriverCurlException: Curl error thrown for http POST to /session with params: {"desiredCapabilities":{"browserName":"chrome","platform":"ANY"}}

Operation timed out after 30001 milliseconds with 0 bytes received

/var/www/html/vendor/facebook/webdriver/lib/Remote/HttpCommandExecutor.php:287
/var/www/html/vendor/facebook/webdriver/lib/Remote/RemoteWebDriver.php:121
/var/www/html/tests/DuskTestCase.php:32
/var/www/html/vendor/laravel/dusk/src/TestCase.php:191
/var/www/html/vendor/laravel/framework/src/Illuminate/Support/helpers.php:639
/var/www/html/vendor/laravel/dusk/src/TestCase.php:192
/var/www/html/vendor/laravel/dusk/src/TestCase.php:111
/var/www/html/vendor/laravel/dusk/src/TestCase.php:85
/var/www/html/tests/Browser/ExampleTest.php:21

ERRORS!
Tests: 3, Assertions: 2, Errors: 1.

So probably I should ask about chrome driver issues in their Google Groups.

matrunchyk on 28 Feb 2017

@matrunchyk The reason it takes forever to show you an error is because TestCase will retry 50 times to connect to the browser as you can see here https://github.com/laravel/dusk/blob/master/src/TestCase.php#L190

Also, you're trying to use display :17, did you make sure to have SupportChrome Trait do that as well? https://github.com/laravel/dusk/blob/master/src/SupportsChrome.php#L67

deleugpn on 28 Feb 2017

@deleugpn I use :17 just for test purposes, checking @SebastianS90 's suggestion.
I changed to :0 display and still no luck.

Probably it's related to Google Chrome binary:

/usr/bin/google-chrome

Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
Illegal instruction

matrunchyk on 28 Feb 2017

@matrunchyk Did you install all the packages listed here? https://medium.com/@splatEric/laravel-dusk-on-homestead-dc5711987595#.p9xorojr2

deleugpn on 28 Feb 2017

@deleugpn I did. Thank you for sharing the article. Unfortunately, it didn't help.
It seems like browser starts loading but hangs, showing error messages related to an inability to connect to a system DBus.

Now I'm trying to use another Docker container with Ubuntu Desktop (GUI), connected to it via VNC to watch what's going on there if the browser starts or not.

matrunchyk on 1 Mar 2017

@simonhunt solution worked in the container of scrutinizer-ci.com but i didnt have to change the code and port at all i just started the a seperate chrome driver in the backgroud before with the command:

nohup ./vendor/laravel/dusk/bin/chromedriver-linux &

and then some steps later after some more yarn npm ect. stuff executed the dusk tests and it worked...

boscowitch on 2 Mar 2017

My Ubuntu just stopped working. No idea what happened. I didn't change anything. I only turn the machine on to run tests and then turn it back off.

root@php7:/var/www/solucoesideais/linus-laravel# php artisan dusk --group=g
PHPUnit 5.7.15 by Sebastian Bergmann and contributors.

E                                                                   1 / 1 (100%)

Time: 7.04 seconds, Memory: 16.00MB

There was 1 error:

1) Tests\Browser\LoginTest::it_should_see_login_form
Facebook\WebDriver\Exception\WebDriverCurlException: Curl error thrown for http POST to /session with params: {"desiredCapabilities":{"browserName":"chrome","platform":"ANY"}}

Operation timed out after 5000 milliseconds with 0 bytes received

/var/www/solucoesideais/linus-laravel/vendor/facebook/webdriver/lib/Remote/HttpCommandExecutor.php:287
/var/www/solucoesideais/linus-laravel/vendor/facebook/webdriver/lib/Remote/RemoteWebDriver.php:121
/var/www/solucoesideais/linus-laravel/tests/DuskTestCase.php:30
/var/www/solucoesideais/linus-laravel/vendor/laravel/dusk/src/TestCase.php:208
/var/www/solucoesideais/linus-laravel/vendor/laravel/dusk/src/TestCase.php:115
/var/www/solucoesideais/linus-laravel/vendor/laravel/dusk/src/TestCase.php:87
/var/www/solucoesideais/linus-laravel/tests/Browser/LoginTest.php:25

ERRORS!
Tests: 1, Assertions: 0, Errors: 1.
root@php7:/var/www/solucoesideais/linus-laravel#

deleugpn on 4 Mar 2017

@deleugpn restart... timeout that sounds more like your webserver didnt restart properly and the test browser simly cant call any pages ...

boscowitch on 5 Mar 2017

@boscowitch I already restarted (server, machine, everything). I just installed a brand new Ubuntu, followed the steps on Medium again (Xvfb, etc;), installed a clean Laravel project with Dusk and the default test fails with that same error message.

In fact, I've seen problems with the web-server. When that happens, Dusk properly fails the test with a screenshot of the ERROR 404 (unable to reach webserver).
The 30000 ms timeout has nothing to do with the webserver itself, but rather with the Browser process timing out any command request to Google Chrome.

deleugpn on 5 Mar 2017

@deleugpn
That 404 error just supports my suspicion that your problem ist not dusk but a wrongly setup webserser / broken laravel project ... if you can see those access tries in the webservers access log files then its settled it's not dusk fault, since to get a 404 on both ends dusk's browser test must be able to start up succesfully chrome ect. (since there are already screenshots) maybe ur configuring a wrong host/url (for example host not configured in the vagrant box or the machine u start dusk in ect. there are a lot of possibilities ) ect.

anyway I think you should not seek more help here since it really doesnt look like dusk is at fault and check other sources for errors ...

boscowitch on 5 Mar 2017

@boscowitch I think you completely misunderstood what I said. What I meant with the 404 and the screenshot is that I've seen it happen. The error that both me and @matrunchyk have been facing (30000 ms timeout) has nothing to do with webserver. It has to do with Dusk not being able to communicate with Google Chrome driver.

deleugpn on 5 Mar 2017

@deleugpn
Well then 404 is confusing since 404 would mean dusk has contacted the webserver and got the response 404... you mean u just have a dusk timeout no 404 response no log entries in the actual webserver logs ...

have you tried the solution of simonhunt it worked great for me i just had to start the whole chrome driver manually some seconds before the actual test.

boscowitch on 5 Mar 2017

Increasing timeout to 150 seconds allowed me to gather more information on the problem.

    protected function driver() {
        return RemoteWebDriver::create(
            'http://localhost:9515',
            $capabilities, 150000, 150000
        );
    }

With that, I started getting

root@dusk:/var/www/solucoesideais/laravel-dusk# php artisan dusk
PHPUnit 5.7.15 by Sebastian Bergmann and contributors.

E                                                                   1 / 1 (100%)

Time: 1.91 minutes, Memory: 10.00MB

There was 1 error:

1) Tests\Browser\ExampleTest::testBasicExample
Facebook\WebDriver\Exception\UnrecognizedExceptionException: chrome not reachable
  (Driver info: chromedriver=2.27.440175 (9bc1d90b8bfa4dd181fbbf769a5eb5e575574320),platform=Linux 4.4.0-31-generic x86_64)

And the only solution I have for it so far is to run chrome with no-sandbox option.

    protected function driver() {
        $chromeOptions = new ChromeOptions();
        $chromeOptions->addArguments(['no-sandbox']);
        $capabilities = DesiredCapabilities::chrome();
        $capabilities->setCapability(ChromeOptions::CAPABILITY, $chromeOptions);

        return RemoteWebDriver::create(
            'http://localhost:9515',
            $capabilities, 150000, 150000
        );
    }

With the no-sandbox flag I am able to use Dusk successfully.

deleugpn on 5 Mar 2017

👍3

hmm strange, no-sanbox saves memory and threads with chrome.... maybe starting chrome from php is taking up too much memory or threads and hitting some limits (php or OS or hardware without swap...) normally sandbox should be better than no sandbox since the main development focus is on the common mode..., why did you try that option anyways ? what did you read that made you try ?

boscowitch on 5 Mar 2017

Yeah, the same for me. I tried '--no-sandbox', because Chrome suggested me to do so. I think it would be good to have the setting in Dusk.

matrunchyk on 5 Mar 2017

👍2

After getting chrome not reachable, I researched it on the internet and the first link was http://stackoverflow.com/questions/28364012/webdriver-exception-chrome-not-reachable.
The accepted answer suggests no-sandbox.

I read about it and it is related to web safety. Google suggests it's better to use another browser than to use Chrome without sandbox (when talking about regular usage). Without sandbox, the browser is more free to access operating system and user files without any restriction, which explains the lack of security. Given the nature of automated tests on a closed environment and a specific web project, the lack of security doesn't worry me right now. I still don't understand why I was able to run Dusk 2 days ago without any issue and now I'm having this problem, but at least I can come back to this some other time.

deleugpn on 5 Mar 2017

👍3

I would try to change some limits of the memory limit of the php cli php.ini ect. since even without --no-sandbox the whole setup works for me if I start the chrome driver seperately without going through php/dusk from the bash commandline... maybe it just really is a simple limit ?

however, why did it work 2 days ago... was there a php apt-get update that maybe changed the php ini... or was it a chrome driver update of the dusk packet .... there must be some origin...

boscowitch on 5 Mar 2017

I've been stuck on it for the last 10 hours. I have no idea what change. The only certainty I had was that nothing had changed. It's not memory resource because it doesn't necessarily have anything to do with PHP. Either way, I tried increasing the machine's RAM and still no change.

By running the driver manually (./vendor/laravel/dusk/bin/chromedriver-linux --verbose), I am able to use POSTMAN to request Google Chrome to be open (with no-sandbox). Without it, it also responds with the same error message.
Basically what RemoteWebDriver does is make a HttpRequest to the Driver service with the url /session and the desired capabilities as POST parameters. I was able to use POSTMAN to replicate this and that's when I noticed that increasing the timeout on PHP would allow me to actually see the error message (chrome not reachable).
The Driver service implements the HTTP protocol to allow us to manipulate the browser and basically what Dusk does is leverage Facebook Web Driver to use the browser through the driver.

deleugpn on 5 Mar 2017

So did Postman get the response?

Best regards,
Sergiy Matrunchyk

matrunchyk on 5 Mar 2017

Another important point to consider when using --no-sandbox is that specific tests results could be different to real visitors with the common mode ... so I think it is worth looking more into why it stopped working without it... I still cant replicate it though our CI runs perfect...

Can one of you please paste some output from the last 2-3 days to see if some other update occured:
/var/log/apt/history.log

another seemingly unrealted packet could have been updated through apt-get upgrade
for example a library that has some influence on chromes behaviour ...
(even though this should be rare if chrome driver has a statically build image it could still be due to libc updates)

boscowitch on 6 Mar 2017

I went to the history.log file, but my memory is not reliable. There's one mention of unattended update on March 3rd. It also lists chromium-browser in the update. Perhaps that could have started this whole issue.

I don't know what version I used to have, but now I have Chromium 56.0.2924.76 Built on Ubuntu , running on Ubuntu 16.04 and apparently the issue is trying to open it with root user. After googling the exact error message

chrome not reachable Driver info: chromedriver=2.27.440175 (9bc1d90b8bfa4dd181fbbf769a5eb5e575574320),platform=Linux 4.4.0-64-generic x86_64

I saw a link that reads chromedriver start under root (#2199) · Issues · GitLab.org / gitlab-ci ... and although it doesn't seem to be anything related to my issue, it gave me the thought of manually starting the chromedriver from a user that is NOT root and then I made the request from Postman and it worked.

deleugpn on 6 Mar 2017

This makes sense, so afterall probably chrome...

there are a lot of linux programms (even ones that require root privileges) but as a safety feature dissallow beeing started as root and only gain more privileges at runtime when needed.

I guess the chrome devs decieded to at least abandon or disregard root support to some extend since its not common or adviced in linux to use root as a user account.

I have been playing and testing around with a local Docker container and Ubuntu 16.04 container for now but there i still can't get it to run.. even with different user

boscowitch on 7 Mar 2017

I think it's a matter of security conflict. Google's sandbox will disallow your access to critical folder and when it tries to block the root user it fails because nobody blocks root!!!. Disabling sandbox allows Chrome to work under root and running it from a user without sudo powers also work just fine.

By running php artisan dusk from a non-sudo user, the chrome process will inherit the permissions of it's parent process (meaning php artisan), so Dusk is able to start Chrome gracefully. The only thing prior to Dusk is making sure Xvfb is up and running on display 0.

deleugpn on 7 Mar 2017

Yeah Im working on Xvfb atm think there is the problem in the docker file....

I think they should add an error output and autoexit in chrome with "not allowed to run as root in sandbox mode" this it at least what most of my package managers do (for example yaourt in archlinux), and that way they often stop me from doing more harm than good.

However the generell rule in linux is try to do as little as possible with root, especially if youre working with webapps and scripting languages such as php..

boscowitch on 7 Mar 2017

👍1

Ok after long testing ect. i got it working in a docker ubuntu 16.04 contianer only with the --no-sandbox option, seperate users non sudo was not enough ...

fortunately i did not have to change code, i just added the option into the /etc/chromium-browser/default option file ... but still not ideal ...

the emost helpfull error was trying to start chromium manually directly in a shell

`DISPLAY=:0 chromium-browser
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
[29557:29557:0307/162305.719813:FATAL:zygote_host_impl_linux.cc(182)] Check failed: ReceiveFixedMessage(fds[0], kZygoteBootMessage, sizeof(kZygoteBootMessage), &boot_pid).

0 0x7fa63e61f02e base::debug::StackTrace::StackTrace()

`

this lead me to the Issue repots hinting to sandboxing problems... I will do more research later maybe there is a way to circumvent using th eno sandbox option....

boscowitch on 7 Mar 2017

Did you try starting Docker with --privileged option?

deleugpn on 7 Mar 2017

In https://github.com/jessfraz/dockerfiles/issues/65 there is also the mentaion of using:
--cap-add SYS_ADMIN

But i havent tired any of that yet since I also don't find it particuallrry usefull changing start parameters of the Docker / container, since I would want my ontainer to run "anywhere" (also third party container enabled SaaS solutions) therefore these kind of solutions are worse to me than changes in the container such as --no-sandboxing (at the same time I also try to not change the code in the webaplications or dusk to have simillar problems by beeing held back due to pending pull requests to our software )

Another solution there seems to use this configuration file:
https://raw.githubusercontent.com/jfrazelle/dotfiles/master/etc/docker/seccomp/chrome.json
but still you have to place it in docker's etc folder on the hosts not something you can do anywhere...

boscowitch on 8 Mar 2017

I think the whole point of DuskTestCase.php and TestCase.php files on your_app/tests/ is to allow customization without requiring changes in the Dusk Library. You can easily add the sandbox argument in DuskTestCase.php and commit that into your project.

/**
 * Create the RemoteWebDriver instance.
 *
 * @return \Facebook\WebDriver\Remote\RemoteWebDriver
 */
protected function driver() {
    $capabilities = DesiredCapabilities::chrome();

    if(env('testing', false)) {
        $chromeOptions = new ChromeOptions();
        $chromeOptions->addArguments(['no-sandbox']);
        $capabilities->setCapability(ChromeOptions::CAPABILITY, $chromeOptions);
    }

    return RemoteWebDriver::create(
        'http://localhost:9515', $capabilities
    );
}

deleugpn on 8 Mar 2017

Hmm that might be true but as the only DevOps/SystemAdmin I would still need make pull Request to all our projects (and future projects) ... it's easier to make just a default Docker config that changes the /etc//chromium-browser/default file with just one line command in the "Dockerfile" :

RUN echo 'CHROMIUM_FLAGS="--no-sandbox" ' > /etc/chromium-browser/default

(Note if you installed the google-chrome-stable package path migh be different this is for the official ubuntu chromium-browser install )

The only thing is that I still would prefer beeing able to use normal sandboxing without giving the container special privilleges from outside/at startup

boscowitch on 8 Mar 2017

Running Dusk as non-root or setting CHROMIUM_FLAGS="--no-sandbox" worked for me. This puts an end to three months of headache trying to make Dusk work in my vagrant box. Thank you!

CyrilMazur on 12 Apr 2017

@deleugpn I have the same issue about the timeout only on my GitLab CI.

So i decided to try your suggestion:

protected function driver()
    {
        $chromeOptions = new ChromeOptions();
        $chromeOptions->addArguments(['no-sandbox']);
        $capabilities = DesiredCapabilities::chrome();
        $capabilities->setCapability(ChromeOptions::CAPABILITY, $chromeOptions);

        return RemoteWebDriver::create(
            'http://localhost:9515',
            $capabilities, 150000, 150000
        );
    }

(on vagrant it works perfectly even without change the driverfunction).

after the command php artisan dusk instead of the timeout error I get this new one:

Facebook\WebDriver\Exception\UnknownServerException: unknown error: Chrome failed to start: exited abnormally
  (Driver info: chromedriver=2.28.455506 (18f6627e265f442aeec9b6661a49fe819aeeea1f),platform=Linux 4.9.16-coreos-r1 x86_64)

giolf on 19 Apr 2017

@giolf It usually means you don't have a screen to run it on. Try to set the display environment with
export DISPLAY=:0. If it doesn't solve, see if running Xvfb manually does it

Xvfb -ac :0 -screen 0 1280x1024x16 &

deleugpn on 19 Apr 2017

@deleugpn thank you for your tip.
I added the display env variable in my script: export DISPLAY=:0 and i get the same error.

So i tried to start manually Xvfb:

export DISPLAY=:0
Xvfb -ac :0 -screen 0 1280x1024x16 &

but i get again the same error.

I'm using this docker image: mightycode/docker-laravel-dusk where it should has everything setup for laver dusk test. It uses debian/jessie.

To be sure i decided to add on my script all the stuff related in this post:
https://medium.com/@splatEric/laravel-dusk-on-homestead-dc5711987595

this is my script that runs on my pipeline:

#!/bin/sh

# makes sure all your repos are up to date
apt-get update -yqq

# chrome dependencies I think
apt-get -y install libxpm4 libxrender1 libgtk2.0-0 libnss3 libgconf-2-4
apt-get -y install libnss3-dev libxi6 libgconf-2-4

# chromium is what I had success with on Codeship, so seemed a good option
apt-get -y install chromium-browser

# XVFB for headless applications
apt-get -y install xvfb gtk2-engines-pixbuf

# fonts for the browser
apt-get -y install xfonts-cyrillic xfonts-100dpi xfonts-75dpi xfonts-base xfonts-scalable

# support for screenshot capturing
apt-get -y install imagemagick x11-apps

# load test environment
cp .env.dusk.testing .env

# generate an application key
php artisan key:generate

# make chrome driver executable
chmod 777 vendor/laravel/dusk/bin/chromedriver-linux

export DISPLAY=:0

# run the Xvfb
Xvfb -ac :0 -screen 0 1280x1024x16 &

# start local server and wait 5 seconds
php artisan serve &
sleep 5

this script is called by my .gitlab-ci.yml file:

test:dusk:
  stage: test
  image: mightycode/docker-laravel-dusk
  script:
  - sh bin/dusk_test.sh
  - php artisan dusk
  dependencies:
  - build:composer

I'm beginning to think the problem is related in the docker image, because if i check the log of the container there is this interesting output related to apt-get -y install chromium-browser instruction:

Package chromium-browser is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'chromium-browser' has no installation candidate

Ok ... the chromium-browser's package is not available ... so i was thinking to add this instruction on my script which chromium-browser(in the order to read the output). Well i figure out that there is no output ... it maybe mean that in the docker image there is not chrome ???

thank you.

giolf on 19 Apr 2017

@giolf this is undeniably a problem with the environment. Dusk is trying to run the browser and it is not managing to do that. I don't have experience with docker, though, so can't be much helpful there. From this link (https://hub.docker.com/r/mightycode/docker-laravel-dusk/~/dockerfile/) it looks like the image is installing Xvfb, Chromium Browser and Google Chrome, no idea why. Maybe it's conflicting with each other? I think I run it on Chromium only (but I'm on Cent OS).

deleugpn on 19 Apr 2017

@deleugpn yes it's possibile. i will try another image. If i found something that work well for the GitLab CI i will post here my setup.

by the way i think @matrunchyk is using docker. Maybe he could attach here some info about the environment that is using on his pipeline ?

thank you

giolf on 19 Apr 2017

@giolf Yes, I use Docker within BitBucket, similar way as GitLab has.

This is my bitbucket-pipelines.yml file (nothing special)

# You can use a Docker image from Docker Hub or your own container registry
image: ivanthecrazy/laravel

environment:
    - DBUS_SESSION_BUS_ADDRESS=/dev/null
    - PIPELINE=1

pipelines:
    default:
        - step:
            script:
                - sh .ci-installer.sh
            services:
                - redis
                - database
    branches:
        master:
            - step:
                script:
                    - sh .ci-installer.sh
                    - sh .do-deploy.sh master
        staging:
            - step:
                script:
                    - sh .ci-installer.sh
                    - sh .do-deploy.sh staging
                services:
                    - redis
                    - database
definitions:
    services:
        redis:
            image: redis
        database:
            image: mysql
            environment:
                MYSQL_ROOT_PASSWORD: XXX
                MYSQL_DATABASE: XXX
                MYSQL_USER: XXX

And .ci-installer.sh script, where all the show goes on:

#!/bin/bash

# Force to exit upon any command which errors.
set -xe
# Pull required keys for some packages
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 46C2130DFD2497F5 A040830F7FAC5991 1397BC53640DB551

# Add Google Chrome repository source
echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" > /etc/apt/sources.list.d/google-chrome.list

# Add NodeJS & Yarn repository sources
curl -sL https://deb.nodesource.com/setup_7.x | bash
echo "deb http://dl.yarnpkg.com/debian/ stable main" > /etc/apt/sources.list.d/yarn.list

# Update package list and install required packages
apt update
apt install -y nodejs yarn php7.0-zip php-redis php-memcached memcached bzip2 google-chrome-stable

# Additional tools
apt-get update && apt install -y python build-essential libnss3 libgconf-2-4 xvfb \
    libnss3-dev libxi6 gtk2-engines-pixbuf xfonts-cyrillic xfonts-100dpi xfonts-75dpi \
    xfonts-base xfonts-scalable imagemagick x11-apps

cp .env.testing .env
composer dump-autoload
composer install --no-interaction --no-progress
php artisan migrate:refresh --seed
yarn
mkdir -p tests/Browser/console
node_modules/.bin/flow-typed install --overwrite

# This does all linting checks and runs "php artisan dusk"
yarn run ci-build

matrunchyk on 19 Apr 2017

@deleugpn i replace the docker/image with this one: shincoder/homestead

it's the copy/paste environment of vagrant but in docker.

It works !
i will post my solution as soon as i clean a bit my CI scripts. see you soon and thx all.

giolf on 19 Apr 2017

👍1

@giolf Thanks! I'd love to take a look at your final solution.

matrunchyk on 19 Apr 2017

I also use Dusk in GitLab CI. With a few adjustments it works fine. Basically, these are:

Use script to emulate a tty
Use Xvfb to provide a virtual X display
Run chrome with --no-sandbox

Provide tty

GitLab CI does not provide a tty in its docker runners, so I had to wrap the dusk command into the script command:

dusk:
  stage: test
  script:
    - chmod +x vendor/laravel/dusk/bin/chromedriver-linux # https://github.com/laravel/dusk/issues/81
    - script -q -e -c 'php artisan dusk' # https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/1021

Use Xvfb

I use my own DuskCommand class. It starts Xvfb once for the whole test suite, not for each single test:

<?php
namespace App\Console\Commands;

use Laravel\Dusk\Console\DuskCommand as BaseCommand;
use Symfony\Component\Process\ProcessBuilder;

class DuskCommand extends BaseCommand
{
    /**
     * The X Display to use
     *
     * @var integer
     */
    protected $xDisplay = 17;

    /**
     * The display resolution for the headless X server
     *
     * @var string
     */
    protected $xDisplayResolution = '1280x720x24';

    /**
     * Setup the Dusk environment to run the given callback.
     *
     * @param  \Closure  $callback
     * @return mixed
     */
    protected function withDuskEnvironment($callback)
    {
        return parent::withDuskEnvironment(function () use ($callback) {
            return $this->withChromeDriver($callback);
        });
    }

    /**
     * Run the given callback with chrome driver.
     *
     * @param  \Closure  $callback
     * @return mixed
     */
    protected function withChromeDriver($callback)
    {
        // Start a headless X server
        $xvfb = (new ProcessBuilder())
            ->setTimeout(null)
            ->add('exec')
            ->add('/usr/bin/Xvfb')
            ->add(':' . $this->xDisplay)
            ->add('-screen')->add('0')->add($this->xDisplayResolution)
            ->getProcess();
        $xvfb->start();

        // Start the chromedriver
        $chrome = (new ProcessBuilder())
            ->setTimeout(null)
            ->add('exec')
            ->add(base_path('vendor/laravel/dusk/bin/chromedriver-linux'))
            ->getProcess()
            ->setEnv(['DISPLAY' => ':' . $this->xDisplay]);
        $chrome->start();

        // Terminate both processes once we are done
        return tap($callback(), function () use ($chrome, $xvfb) {
            $chrome->stop();
            $xvfb->stop();
        });
    }
}

It is registered in AppServiceProvider:

<?php
namespace App\Providers;

use App\Console\Commands\DuskCommand;
use Illuminate\Support\ServiceProvider;
use Laravel\Dusk\DuskServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function register()
    {
        // Laravel Dusk: Must not be registered in production
        // because of the unprotected login route.
        if ($this->app->environment('local', 'testing')) {
            $this->app->register(DuskServiceProvider::class);
            $this->commands(DuskCommand::class);
        }
    }
}

Apply `--no-sandbox`

This is needed because GitLab CI runs your build script as root inside the Docker container. I did this by configuring DuskTestCase as follows:

<?php
namespace Tests;

use Facebook\WebDriver\Chrome\ChromeOptions;
use Facebook\WebDriver\Remote\DesiredCapabilities;
use Facebook\WebDriver\Remote\RemoteWebDriver;
use Laravel\Dusk\TestCase as BaseTestCase;

abstract class DuskTestCase extends BaseTestCase
{
    use CreatesApplication;

    public static function prepare()
    {
        // Chromedriver is already started in custom DuskCommand.
    }

    /**
     * Create the RemoteWebDriver instance.
     *
     * @return \Facebook\WebDriver\Remote\RemoteWebDriver
     */
    protected function driver()
    {
        $chrome = DesiredCapabilities::chrome();
        if (config('app.env_docker')) {
            $chrome->setCapability(
                ChromeOptions::CAPABILITY,
                (new ChromeOptions)->addArguments(['--no-sandbox'])
            );
        }
        return RemoteWebDriver::create('http://localhost:9515', $chrome);
    }
}

You might have noticed that I introduced config('app.env_docker'), so add the following to config/app.php:

    'env_docker' => env('APP_ENV_DOCKER', false),

And your .env file in GitLab CI should contain: APP_ENV_DOCKER=true
This ensures that you use --no-sandbox only as part of your CI pipeline where everything runs in a container, and not on your local machine where this might be a potential security issue.

SebastianS90 on 19 Apr 2017

❤4

@SebastianS90 you don't need a own custom dusk command.

giolf on 19 Apr 2017

This is my setup

NB: at the moment i didn't implement a deploy stage and in my test stage i've to implement mySQL service. But the core to work with Laravel Dusk is all in there :)

.gitlab-ci.yml

stages:
  - build
  - test

before_script:
  - '[[ ! -e /.dockerenv ]] && exit 0'

composer:
  stage: build
  image: shincoder/homestead
  script:
    - sh bin/composer_build.sh
  artifacts:
    paths:
      - vendor/

dusk:
  stage: test
  image: shincoder/homestead
  script:
    - sh bin/dusk_test.sh
    - php artisan dusk
  dependencies:
    - composer

composer_build.sh

#!/bin/sh

# setup php libraries.
composer install --no-interaction --optimize-autoloader

dusk_tests.sh

#!/bin/sh

# makes sure all your repos are up to date
apt-get update -yqq

# laravel dusk dependencies
apt-get -y install chromium-browser libxpm4 libxrender1 libgtk2.0-0 libnss3 \
    libgconf-2-4 libnss3-dev libxi6 libgconf-2-4 xvfb gtk2-engines-pixbuf \
    xfonts-cyrillic xfonts-100dpi xfonts-75dpi xfonts-base xfonts-scalable \
    imagemagick x11-apps

# load test environment
cp .env.dusk.testing .env

# generate an application key. Re-cache.
php artisan key:generate

# make chrome driver executable
# chmod 777 vendor/laravel/dusk/bin/chromedriver-linux

# run the 'graphic' server
Xvfb -ac :0 -screen 0 1280x1024x16 &

# start local server and wait 4 seconds
php artisan serve &
sleep 5

DuskTestCase.php

    /**
     * Create the RemoteWebDriver instance.
     *
     * @return \Facebook\WebDriver\Remote\RemoteWebDriver
     */
    protected function driver()
    {
        $chromeOptions = new ChromeOptions();
        $chromeOptions->addArguments(['no-sandbox']);
        $capabilities = DesiredCapabilities::chrome();
        $capabilities->setCapability(ChromeOptions::CAPABILITY, $chromeOptions);

        return RemoteWebDriver::create(
            'http://localhost:9515',
            $capabilities, 150000, 150000
        );
    }

giolf on 19 Apr 2017

👍6

@SebastianS90 awesome setup! Thank you for the contribution. Just a side-note: you might not need to deal with Tty anymore with #226

deleugpn on 19 Apr 2017

I followed this solution of @tzurbaev here, it worked for me. It says for Vagrant on Ubuntu 14.04 but it actually works on 16.04.

Hope this helps.

jhunexjun on 24 May 2017

On Ubuntu Linux 16.04, I got this to work:

Install Chromium & dependencies for headless testing
sudo apt-get -y install chromium-browser xvfb gtk2-engines-pixbuf xfonts-cyrillic xfonts-100dpi xfonts-75dpi xfonts-base xfonts-scalable imagemagick x11-apps

Create a customDuskCommand
Which extends the original, with this handle method:

    public function handle()
    {
        $xvfb = (new ProcessBuilder())
            ->setTimeout(null)
            ->setPrefix('/usr/bin/Xvfb')
            ->setArguments(['-ac',  ':0', '-screen', '0', '1280x1024x16'])
            ->getProcess();

        $xvfb->start();

        try {
            parent::handle();
        } finally {
            $xvfb->stop();
        }

        return;
    }

stephangroen on 1 Jun 2017

👍1

In my case following suggestions didn't work:

changing premissions to chromedrive- files didn't work - in fact even though I was executing the chmod command permissions were not changed
installing Chrome and other libraries

What worked for me was simply starting the xvfb server by running the

Xvfb :0 -screen 0 1280x960x24 &

command. Nothing more, nothing less, it did the trick. With xvfb started I'm finally able to run the tests inside Vagrant.

bognix on 6 Jun 2017

@stephangroen

̉Where should I place the Custom Dusk Command? I made one as recommmended but I don't know where to place the file.

javier-pino on 13 Jun 2017

@javier-pino
Default location for Laravel Artisan commands is app/Console/Commands.
Remember to also register the command: https://laravel.com/docs/5.4/artisan#registering-commands

stephangroen on 13 Jun 2017

Any clue how to make it available to run Dusk in fresh Linux installation? It works fine in Homestead, but when I try to do the same on fresh Ubuntu installation (Docker), I run first:

apt-get -y install libxpm4 libxrender1 libgtk2.0-0 \
libnss3 libgconf-2-4 chromium-browser \
xvfb gtk2-engines-pixbuf xfonts-cyrillic \
xfonts-100dpi xfonts-75dpi xfonts-base \
xfonts-scalable imagemagick x11-apps

and then

Xvfb :0 -screen 0 1280x960x24 &

but it still doesn't work. I'm getting:

Facebook\WebDriver\ExceptionWebDriverCurlException: Curl error thrown for http POST to /session with params: {"desiredCapabilities":{"browserName":"chrome","pl atform":"ANY","chromeOptions":{"binary":"","args":["--disable-gpu","--headless"] }}}

Operation timed out after 30000 milliseconds with 0 bytes received

mnabialek on 17 Sep 2017

👍2

I was generating the same error, but that was why
$browser->resize(1024, 768); // Width and Height
change it in:

protected function driver()
    {
        $options = (new ChromeOptions())->addArguments([
            '--disable-gpu',
            '--headless',
            '--window-size=1024, 768',
        ]);

        return RemoteWebDriver::create(
            'http://localhost:9515', DesiredCapabilities::chrome()->setCapability(
                ChromeOptions::CAPABILITY, $options
            )
        );
    }

and it worked ok

guduchango on 7 Nov 2017

👍3

SOLVED!!!

In DuskTestCase.php File

Old Code of driver():

protected function driver()
    {
        $options = (new ChromeOptions)->addArguments([
            '--disable-gpu',
            '--headless',
            '--window-size=1920,1080',
        ]);

        return RemoteWebDriver::create(
            'http://localhost:9515', DesiredCapabilities::chrome()->setCapability(
                ChromeOptions::CAPABILITY, $options
            )
        );
    }

Just Add '--no-sandbox' flag

New Code:

protected function driver()
    {
        $options = (new ChromeOptions)->addArguments([
            '--disable-gpu',
            '--headless',
            '--window-size=1920,1080',
            '--no-sandbox'
        ]);

        return RemoteWebDriver::create(
            'http://localhost:9515', DesiredCapabilities::chrome()->setCapability(
                ChromeOptions::CAPABILITY, $options
            )
        );
    }

amitbk on 5 Feb 2019

@amitbk The --no-sandbox flag is necessary when executing Chromedriver/Chrome/Chromium as root.

wells on 18 Feb 2019

Dusk: Can't run dusk tests on ubuntu 16.04

Most helpful comment

All 76 comments

So did Postman get the response?

0 0x7fa63e61f02e base::debug::StackTrace::StackTrace()

Provide tty

Use Xvfb

Apply `--no-sandbox`

This is my setup

.gitlab-ci.yml

composer_build.sh

dusk_tests.sh

DuskTestCase.php

Related issues

Dusk: Can't run dusk tests on ubuntu 16.04

Most helpful comment

All 76 comments

So did Postman get the response?

0 0x7fa63e61f02e base::debug::StackTrace::StackTrace()

Provide tty

Use Xvfb

Apply --no-sandbox

This is my setup

.gitlab-ci.yml

composer_build.sh

dusk_tests.sh

DuskTestCase.php

Related issues

Apply `--no-sandbox`