Issue metadata
Sign in to add a comment
|
Chrome crashes/fails to load when /dev/shm is too small, and location can't be overridden
Reported by
aatr...@gmail.com,
Apr 26 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36 Steps to reproduce the problem: 1. Create a Docker container with the default /dev/shm size (64MB) or smaller (ideally, say, 10MB) 2. Launch Chrome inside the container 3. Browser may fail to load entirely. If not, attempt to browse to any mid-weight site, and either the tab or the browser will crash. The above will occur even if there is a larger tmpfs partition (e.g. 512MB) available on the Docker container. Chrome insists on using the tiny /dev/shm partition to its own detriment, and it is not possible to modify this behavior. What is the expected behavior? Chrome should launch and load websites normally. What went wrong? The intent of this bug is to create a command-line flag or environment variable check that allows a user to specify a different path for Chrome to use instead of /dev/shm. On most desktop Linux distributions, the default /dev/shm partition is large enough. However, on many cloud providers using Docker containers (such as the Google App Engine Flexible Environment) or Heroku, the default /dev/shm size is appreciably smaller (64MB and 5MB, respectively). On these platforms it's impossible to change the size of /dev/shm, which makes using Chrome difficult or impossible. This is particularly an issue for those who want to take advantage of its new headless mode. If a command-line flag were added, e.g. --shared-memory-path=/tmp, it would become possible to use Chrome on these platforms. Crashed report ID: How much crashed? Whole browser Is it a problem with a plugin? No Did this work before? No Chrome version: 59.0.3067.0 Channel: dev OS Version: Debian GNU/Linux 8.7 (jessie) Flash Version:
,
Apr 26 2017
Seems to out of scope for TE.Hence adding the respective label for triaging the issue. Thanks!
,
Jun 6 2017
Chrome 59 was just released, but the headless mode is still not usable inside Docker containers with default settings due to this issue. Is there anything I can do to help with triage/reproducing the issue?
,
Jul 27 2017
Any updates?
,
Aug 16 2017
This is blocking me from running on appengine flex since the size of /dev/shm is immutable
,
Aug 16 2017
Blocking me from running on Flex as well.
,
Aug 16 2017
This is apparently an issue for running on AWS Lambda as well: https://medium.com/@marco.luethy/running-headless-chrome-on-aws-lambda-fa82ad33a9eb.
,
Sep 26 2017
,
Sep 26 2017
It may be helpful to fully understand the situation and limitations, before evaluating any suggested changes to Chromium. So out of curiousity, for the affected containers / VMs: a) Does the user that want to run Chromium have root privileges? b) Is /dev/shm the actual mount point for a tmpfs partition that is too small for Chromium's use? Or is /dev/shm just a symlink to elsewhere? c) Is it the case that whatever tmpfs partition /dev/shm ultimately points to is too small, but there exists another tmpfs partition elsewhere (e.g. /tmp) that is big enough for Chromium's needs?
,
Sep 26 2017
I am trying to run chromium on Google App Engine Flexible. These are all Google products, would be nice if they worked together. Here are the answers for me: a) I don't think I have root access. If I try to umount /dev/shm and reallocate it I get permissions errors. b) /dev/shm is an actual mount point. c) Yes, I can easily allocate other tmpfs mount points that are large. It's just that Docker's default /dev/shm size is only 64MB, and I have no control over the process that runs the docker image.
,
Oct 25 2017
I have a similar issue with Google Container Engine and was going to try GAE Flexible until I learned that it also runs on Docker. Once I deployed my code to Google Compute Engine, everything just worked.
,
Dec 1 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by reve...@chromium.org
, Apr 26 2017