search

laravel / dusk

Laravel Dusk provides simple end-to-end testing and browser automation.
https://laravel.com/docs/dusk
MIT License
1.88k stars 322 forks source link

Can't run dusk tests on ubuntu 16.04 #10

Closed babanesma closed 7 years ago

babanesma commented 7 years ago

I am trying laravel dusk on a fresh installation laravel 5.4.x-dev This is what I get when I run php artisan dusk 

PHPUnit 5.7.5 by Sebastian Bergmann and contributors.

Runtime:       PHP 7.0.13-0ubuntu0.16.04.1 with Xdebug 2.4.0
Configuration: /var/www/html/dusk/phpunit.dusk.xml

E                                                                   1 / 1 (100%)

Time: 2.5 minutes, 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"}}

Operation timed out after 30000 milliseconds with 0 bytes received

/var/www/html/dusk/vendor/facebook/webdriver/lib/Remote/HttpCommandExecutor.php:287
/var/www/html/dusk/vendor/facebook/webdriver/lib/Remote/RemoteWebDriver.php:121
/var/www/html/dusk/tests/DuskTestCase.php:32
/var/www/html/dusk/vendor/laravel/dusk/src/TestCase.php:176
/var/www/html/dusk/vendor/laravel/framework/src/Illuminate/Support/helpers.php:639
/var/www/html/dusk/vendor/laravel/dusk/src/TestCase.php:177
/var/www/html/dusk/vendor/laravel/dusk/src/TestCase.php:107
/var/www/html/dusk/vendor/laravel/dusk/src/TestCase.php:81
/var/www/html/dusk/tests/Browser/ExampleTest.php:21

ERRORS!
Tests: 1, Assertions: 0, Errors: 1.
simonhunt commented 7 years ago

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).

nuzkito commented 7 years ago

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.

babanesma commented 7 years ago

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

trideout commented 7 years ago

This is resolved with PR #33 and should be closed

nuzkito commented 7 years ago

Apparently works perfectly. Thanks @trideout !

KKSzymanowski commented 7 years ago

@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.

mrdevries commented 7 years ago

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?

babanesma commented 7 years ago

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

KKSzymanowski commented 7 years ago

@babanesma Thanks.

zgosalvez commented 7 years ago

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?

mrdevries commented 7 years ago

@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.

zgosalvez commented 7 years ago

@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

nickpoulos commented 7 years ago

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?

BondITSolutions commented 7 years ago

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.
deleugpn commented 7 years ago

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?

alex621 commented 7 years ago

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.

deleugpn commented 7 years ago

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.

liepumartins commented 7 years ago

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

browner12 commented 7 years ago

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

deleugpn commented 7 years ago

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.

mattkoch614 commented 7 years ago

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

matrunchyk commented 7 years ago

Still doesn't work in Docker.

Operation timed out after 30000 milliseconds with 0 bytes received

deleugpn commented 7 years ago

@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.

matrunchyk commented 7 years ago

@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.

SebastianS90 commented 7 years ago

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

matrunchyk commented 7 years ago

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

  1. /usr/bin/Xvfb :17 -screen 0 1280x720x24 &
  2. DISPLAY=:17 vendor/laravel/dusk/bin/chromedriver-linux --verbose --log-path=driver.log &
  3. 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\Exception\WebDriverCurlException: 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.

deleugpn commented 7 years ago

@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

matrunchyk commented 7 years ago

@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

deleugpn commented 7 years ago

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

matrunchyk commented 7 years ago

@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.

boscowitch commented 7 years ago

@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...

deleugpn commented 7 years ago

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#
boscowitch commented 7 years ago

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

deleugpn commented 7 years ago

@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.

boscowitch commented 7 years ago

@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 ...

deleugpn commented 7 years ago

@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.

boscowitch commented 7 years ago

@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.

deleugpn commented 7 years ago

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.

boscowitch commented 7 years ago

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 ?

matrunchyk commented 7 years ago

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.

deleugpn commented 7 years ago

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.

boscowitch commented 7 years ago

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...

deleugpn commented 7 years ago

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.

matrunchyk commented 7 years ago

So did Postman get the response? -- Best regards, Sergiy Matrunchyk

boscowitch commented 7 years ago

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)

deleugpn commented 7 years ago

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.

boscowitch commented 7 years ago

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

deleugpn commented 7 years ago

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.

boscowitch commented 7 years ago

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 commented 7 years ago

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....