Skip to content
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.

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

Chrome fails to launch in headless mode #2235

Closed
nesl247 opened this issue Jun 19, 2017 · 18 comments
Closed

Chrome fails to launch in headless mode #2235

nesl247 opened this issue Jun 19, 2017 · 18 comments
Assignees

Comments

@nesl247
Copy link

nesl247 commented Jun 19, 2017

I'm trying to run chrome in headless mode to integrate it into Karma. Unfortunately it doesn't seem to be working in WSL at all.

Running: Microsoft Windows [Version 10.0.15063]

/opt/google/chrome/chrome --headless --disable-gpu --remote-debugging-port=9222 https://chromestatus.com
clone: Invalid argument
fish: “/opt/google/chrome/chrome --hea…” terminated by signal SIGTRAP (Trace or breakpoint trap)

Attached is the output of strace.

chrome1.log.txt
chrome2.log.txt
chrome3.log.txt

@therealkenc
Copy link
Collaborator

#648 (message)

@fpqc
Copy link

fpqc commented Jun 20, 2017

@nesl247 To summarize that thread for you, by default, chrome uses two Linux features that are currently unimplemented surface in WSL, namely namespaces/sandboxes, and udev. Ken wrote a stub library that just returns "all clear" for libudev calls, and you also need to run without the sandbox.

@stehufntdev
Copy link
Collaborator

Thanks for reporting the issue. Closing this out as a duplicate.

@nesl247
Copy link
Author

nesl247 commented Jun 20, 2017

@stehufntdev Why close it as a duplicate, the other is not open.

@nesl247
Copy link
Author

nesl247 commented Jun 20, 2017

Also thanks to everyone else for the info.

@stehufntdev
Copy link
Collaborator

Sorry, I thought the other one was still open. Re-opened for now.

@stehufntdev stehufntdev reopened this Jun 20, 2017
@therealkenc
Copy link
Collaborator

Sorry, I thought the other one was still open. Re-opened for now.

More the merrier.

Fundamentally this is a dupe of #1121. The trap above is actually because of CLONE_NEWUSER, which was reported in #1029 and was mentioned in #1005 (message). That can be worked around with --no-sandbox like @fpqc mentioned. Also blocking is #1006 (which in this context is really #486).

@fpqc
Copy link

fpqc commented Jun 21, 2017

By the way, user namespaces will return a similar error on Arch, which has consistently refused to ship with the User Namespaces functionality and patches enabled (a stance that has been vindicated several times with the numerous vulnerabilities that have been discovered in UNS since then). They choose instead to setuid on the sandbox, or something to that effect, I believe.

I'm actually curious how the sandbox will fail on an Arch image. Possibly it might fail due to unix capabilities again (like ping was failing in an issue earlier), but then I wonder what if I setuid it. Gonna roll your libudev stub for Arch, probably write a PKGBUILD in case others want to try it and report back.

@fpqc
Copy link

fpqc commented Jun 21, 2017

Update: The setuid sandbox fails differently but fundamentally again on another clone flag, going to open a new issue.

@chadbr
Copy link

chadbr commented Jul 24, 2017

fwiw (I hate to be a wet blanket), not being able to launch chrome to run karma tests kind of kills using WSL for me (and my team...)

There's no way to run the same node_modules install from windows and WSL, so you're left removing / reinstalling on the windows side to run tests -- in which case why am I bothering with WSL...?

Is it possible to launch any browser from the WSL side for karma testing?

@benhillis
Copy link
Member

@chadbr - Firefox works well for me provided you have an X11 server listening on DISPLAY=0:0

@chadbr
Copy link

chadbr commented Jul 24, 2017

giphy

@benhillis
Copy link
Member

@chadbr - excellent....

@benhillis
Copy link
Member

Fixed in 16273.

@saschanaz
Copy link

I'm still seeing error on 16299.15, should I file another issue or just here?

$ chromium-browser --headless --disable-gpu --remote-debugging-port=9222 https://chromestatus.com
Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting.
Aborted (core dumped)

@therealkenc
Copy link
Collaborator

Assertion 'pthread_mutex_unlock(&m->mutex) == 0'

That's #486 aka #1006. Instructions in #648 here.

@therealkenc
Copy link
Collaborator

This was dupe #1121 and fixedfallcreatorsupdate (along with #648 which was never materially different than this issue).

@mcfiredrill
Copy link

Not having any luck either...

 tony@dokkebi  /c/Users/mcfir/src/datafruits   master   chromium-browser --headless --disable-gpu --remote-debugging-port=9222 https://chromestatus.com
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Permission denied
[1]    11661 trace trap (core dumped)  chromium-browser --headless --disable-gpu --remote-debugging-port=9222
 tony@dokkebi  /c/Users/mcfir/src/datafruits   master  sudo  chromium-browser --headless --disable-gpu --remote-debugging-port=9222 https://chromestatus.com
[sudo] password for tony:
[0407/143246.962865:ERROR:zygote_host_impl_linux.cc(89)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.
 tony@dokkebi  /c/Users/mcfir/src/datafruits   master  sudo  chromium-browser --headless --no-sandbox --disable-gpu --remote-debugging-port=9222 https://chromestatus.com
shared memfd open() failed: Function not implemented
Home directory not accessible: Permission denied

DevTools listening on ws://127.0.0.1:9222/devtools/browser/628abba1-7c8f-4609-807b-7d47b0c46434
[0407/143308.957098:FATAL:gpu_data_manager_impl_private.cc(892)] The display compositor is frequently c
rashing. Goodbye.
[1]    11680 trace trap (core dumped)  sudo chromium-browser --headless --no-sandbox --disable-gpu

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants