-
Notifications
You must be signed in to change notification settings - Fork 822
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
Google Chrome (headless) errors #3282
Comments
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:
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 |
One more data point, since it is bound to come up eventually. On 17686 and 67.0.3396.79, headfull Chrome fails thus:
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. |
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. |
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 This wasn't as much of a problem back in 2016 when the only thing people reasonably expected to work was |
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". |
I got the following error for passing the "--no-sandbox" |
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:
I'm running Chrome in this case with the flags |
For above issue on WSL1 it was enough to run WSL as admin or use Without admin or
The solution is to run WSL as admin or use
This warning is ok because we will run chrome with following options:
|
For me I just keep getting this when trying to run
Ironically I've been able to get non-headless (headful?) working, but headless would be better for testing :/ |
I got the same error when running Any hints on how did you get it to run non-headless? I failed with either non-headless or headless. For non-headless mode, I did google-chrome-stable --no-sandbox
# [31222:31222:0330/125021.842748:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id
# [31222:31256:0330/125021.846515:ERROR:udev_watcher.cc(61)] Failed to enable receiving udev events.
# [31222:31271:0330/125021.914188:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
# [31222:31271:0330/125021.932517:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
# [31222:31271:0330/125021.932559:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
# [31222:31317:0330/125022.062926:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
# [31222:31317:0330/125022.063941:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
# [31222:31317:0330/125022.065537:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
# [31267:31267:0330/125022.196704:ERROR:viz_main_impl.cc(161)] Exiting GPU process due to errors during initialization
# [31222:31255:0330/125022.337900:FATAL:scoped_file.cc(43)] : Bad file descriptor (9)
# [0330/125022.338439:ERROR:nacl_helper_linux.cc(308)] NaCl helper process running without a sandbox!
# Most likely you need to configure your SUID sandbox correctly
# [1] 31222 trace trap (core dumped) google-chrome-stable --no-sandbox |
I realised after posting this that I didn't actually manage to get it running properly in headful: it would sometimes render initially, but I could never get it to load any webpages - the tabs would just always crash 😢 |
Is there anything new on this? :'( Impossible to run google-chrome in my Ubuntu 18.04.5 LTS with WSL 1. |
ver
at a Windows Command Prompt)MS Win Version: 10.0.17134 Build 17134
$ 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.
The text was updated successfully, but these errors were encountered: