Google Chrome (headless) errors

[lfurzewaddock]

• Your Windows build number: (Type ver at a Windows Command Prompt)

MS Win Version: 10.0.17134 Build 17134

• What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)

$ google-chrome --headless --disable-gpu --dump-dom https://www.chromestatus.com/

output

[0606/230417.381147:ERROR:gpu_process_transport_factory.cc(1017)] Lost UI shared context.

[therealkenc]

Yeah, this one is happening with folks on headless Real Linux (f.e. a Docker container) too, like here. I was able to get the following to work:

$ google-chrome --no-gpu --no-sandbox --disable-setuid-sandbox --headless --dump-dom http://www.chromestatus.com

But YRMV. This was with Chrome 67.0.3396.79 and 68.0.3440.15. Unfortunately there isn't much in the way of a WSL actionable here. You could start looking for a diverge against a headless Real Linux VM with a CONFIG_DRM=n kernel, but smart money says you'll get the same result there too.

[therealkenc]

One more data point, since it is bound to come up eventually. On 17686 and 67.0.3396.79, headfull Chrome fails thus:

$ google-chrome
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Permission denied
Failed to generate minidump.Illegal instruction (core dumped)

I haven't dug into it, but the error message by itself is curious because (AFAIK) we don't have network namespaces. What might be happening here is Chrome is getting confused by the WSL's unusual set of supported / unsupported namespace features. If that's the case it might well run in a headless VM, but who knows without trying.

[Brian-Perkins]

Network namespaces are supported, but only when you are running elevated, which puts them somewhere in the partially supported WSL feature category. This is because Windows actually supports a concept much like a Linux network namespace, but just as Linux requires 'sudo' to use them due to the side-effects, Windows requires elevated admin privileges. This is not ideal, and from the beginning there have been suggestions to integrate sudo better, but currently the only option is to run elevated.

[therealkenc]

I had wondered but didn't have my container thing handy to try (hence the hedge). That run above wasn't elevated of course, but Chrome is under the impression network namespace available anyway. The message doesn't mean much though, since by that point Chrome has skidded off the track and probably doesn't know up from down.

But yep, recent Chrome (headless and otherwise) works fine if you start WSL escalated. So there's your work-around.

That UserVoice you mention is more about people annoyed by the popup notification. Mapping WSL UID 0 to Windows Administrator privileges is another matter. I empathise entirely that the problem worms real fast. I've just about got WSL nmap running and understand the dilemma. But the more surface you guys cover, the higher the risk that "You need to run WSL as Administrator or it doesn't work right" becomes idiomatic. Which is classic security anti-pattern.

This wasn't as much of a problem back in 2016 when the only thing people reasonably expected to work was ping. If people start using WSL elevated just so they can run their webpage test scripts, that gets more ugly.

[benken-parasoft]

One more data point, since it is bound to come up eventually. On 17686 and 67.0.3396.79, headfull Chrome fails thus

I see this same "Failed to move to new namespace ... Permission denied" error from Chrome 71 on Windows 1809 (17763) with Ubuntu 18.04. For headfull, a workaround is to pass "--no-sandbox".

[feryandi]

I got the following error for passing the "--no-sandbox"
[0602/230132.465909:ERROR:nacl_helper_linux.cc(310)] NaCl helper process running without a sandbox! Most likely you need to configure your SUID sandbox correctly
Can somebody help?

[derrelldurrett]

I have what appears to be a problem related to the issue reported here. I'm attempting to use Chromedriver under WSL (I'm using Ubuntu 18.04) to run headless tests under Rails/Cucumber/Capybara/Selenium.

My environment:

• Operating system / CI Environment: Microsoft Windows [Version 10.0.18362.239] with WSL running Ubuntu 18.04 [Linux version 4.4.0-18362-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) Will this be Open Source? #1-Microsoft Mon Mar 18 12:02:00 PST 2019]
• Ruby/Rails version: 2.6.1p33 (2019-01-30 revision 66950) [x86_64-linux]/5.2.3
• Browser and version: Google Chrome 75.0.3770.100
• Webdrivers::Chromedriver.required_version = '75.0.3770.140'

      unknown error: Chrome failed to start: crashed
        (unknown error: DevToolsActivePort file doesn't exist)
        (The process started from chrome location /usr/bin/google-chrome is no longer running, so ChromeDriver is assuming that Chrome has crashed.) (Selenium::WebDriver::Error::UnknownError)
      #0 0x7f8211ae07a9 <unknown>

I'm running Chrome in this case with the flags headless single-process no-gpu no-sandbox disable-setuid-sandbox, but have also tried disable-gpu proxy-server="direct://" disable-dev-shm-usage proxy-bypass-list="*", all to no effect.

[twistezo]

For above issue on WSL1 it was enough to run WSL as admin or use sudo and after chrome with specific options.

Without admin or sudo:

$ google-chrome 
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Permission denied
Trace/breakpoint trap (core dumped)

The solution is to run WSL as admin or use sudo:

$ sudo google-chrome -v
(google-chrome:12596): Gtk-WARNING **: 15:07:50.906: cannot open display:        

This warning is ok because we will run chrome with following options:

$ google-chrome --no-sandbox --disable-gpu --disable-features=VizDisplayCompositor --headless --dump-dom https://www.chromestatus.com

[lewisdonofrio]

For what it's worth Firefox (sync not working with duo but that is a firefox issue not wsl), Arora, Dillo all working fine within WSL1
(chromium seems to start but then all the extensions crash and recrash, over and over again)