'--disable-dev-shm-usage' does not resolve the Chrome crash issue in Docker

Question

Since our e2e test has expanded to over 50+ tests we decided to run tests in parallel to speed it up. Since default gitlab pipeline has limited resources (and dev-shm-size trick did not worked) we decided to use our own AWS runner. For those who are running Protractor tests in Docker it's known that you have to add this flags to prevent the browser crash issue:

chromeOptions: {
                args: [
                    "--no-sandbox",
                    "--headless",
                    "--disable-gpu",
                    "--disable-dev-shm-usage"
                ]

At least that's what I managed to found so far on the web.

I'm using multicapabilities and Puppeteer to run my e2e tests in Docker with the Chrome arguments provided above. In default gitlab runner tests starts but most likely will randomly fail with random timeout errors. I was trying to resolve this for almost a week when all of sudden it appeared that this timeout issues occurs due to the know bug and what actually happens is that the browser is crashing in docker. However now (when switched to our runner) I'm facing the "DevToolsActivePort file doesn't exist" error when using AWS runner.

[chrome #01] WebDriverError: unknown error: DevToolsActivePort file doesn't exist
[chrome #01]   (Driver info: chromedriver=2.44.609551 (5d576e9a44fe4c5b6a07e568f1ebc753f1214634),platform=Linux 4.4.0-1052-aws x86_64)

When using default free Gitlab runner tests are pretty flaky; slow; and fails randomly (that's why we decided to use our own runner). But when using our runner test does not even start due to the error above. And again this error should not occur since all required flags are present in Protractor config. How can I resolve the 'DevToolsActivePort file doesn't exist' issue when using custom runner? Here is a part of Protractor config

multiCapabilities: [
        {
            browserName: "chrome",
            specs: ["./src/dashboard-spec.ts"],
            chromeOptions: {
                args: [
                    "--no-sandbox",
                    "--headless",
                    "--disable-gpu",
                    "--disable-dev-shm-usage",
                    "--window-size=1920,1040",
                ],
                binary: puppeteer.executablePath(),
            },
        },
        {
            browserName: "chrome",
            specs: ["./src/smoke-test.ts"],
            chromeOptions: {
                args: [
                    "--no-sandbox",
                    "--headless",
                    "--disable-gpu",
                    "--disable-dev-shm-usage",
                    "--window-size=1920,1040",
                ],
                binary: puppeteer.executablePath(),
            },
        },
    ],

UPDATE I'm using

webdriver-manager update --standalone false --gecko false --versions.chrome 2.44

I know you may suggest to update the webdriver but this version is the only one which I managed to get work with Puppeteer

UPDATE 2 Docker file:

RUN wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - \
    && sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' \
    && apt-get update \
    && apt-get install -y google-chrome-stable xvfb gtk2-engines-pixbuf xfonts-cyrillic xfonts-100dpi xfonts-75dpi xfonts-base xfonts-scalable imagemagick x11-apps default-jre \
      --no-install-recommends \
      ruby && \
      gem install s3_website \
    && rm -rf /var/lib/apt/lists/*


RUN \
  npm install npm@latest -g &&\
  npm install -g @angular/cli

Everything is working fine (except slowness, flakiness, random timeouts etc.etc.) both locally and on free gitlab runner. But not when we are attempting to use our own runner

Answer 1

Old question but a similar issue nearly drove me to insanity so sharing my solution:

When I updated my Docker image Chrome installation from an old version to Chrome 86, I got this error. My setup was not identical but we were instantiating Chrome through a selenium webdriver.

The solution was to pass the options as goog:chromeOptions hash instead of chromeOptions hash. I truly don't know if this was a Selenium, Chrome, Chromedriver, or some other update, but maybe some poor soul will find solace in this answer in the future.

Answer 2

I think I found the problem in my case

if I run df -h I would get among others this

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       16G   15G  547M  97% /

The problem started happening a little earlier, when probably the space was not critical, lets say 80% and this is why I missed it

I turns out that my /var/jenkins/workspace was like 10Gb because I was archiving reports for a year without knowing this, because of my jenkins HTML publisher setting

The solution for me was

1. to remove old reports from the directory
2. to set keep-all flag to false, to prevent overfilling in future since I was archiving reports anyway

publishHTML([
    allowMissing: true,
    alwaysLinkToLastBuild: false,
    includes: '**/*',
    keepAll: true, <--------------- this guy
    reportDir: 'reports/',
    reportFiles: reports,
    reportName: 'HTML Report',
    reportTitles: tabs
])

3. and to add extra 4 Gb to the /dev/xvda1