Unhandledpromiserejectionwarning error failed to launch the browser process

Headless Chrome Node.js API. Contribute to puppeteer/puppeteer development by creating an account on GitHub.

Troubleshooting

:::caution

Chromium currently does not provide arm64 binaries for Linux. There are only
binaries for
Mac ARM with experimental support from Puppeteer.

:::

Cannot find module 'puppeteer-core/internal/...'

This can occur is your Node.js version is lower than 14 or you are using a
custom resolver (such as
jest-resolve). For the former,
we do not support deprecated versions of Node.js. For the latter, usually
upgrading the resolver (or its parent module such as jest) will work (e.g.
#9121)

Could not find expected browser locally

Starting from v19.0.0, Puppeteer will download browsers into
~/.cache/puppeteer using
os.homedir for better caching
between Puppeteer upgrades. Generally the home directory is well-defined (even
on Windows), but occasionally the home directory may not be available. In this
case, we provide the PUPPETEER_CACHE_DIR variable which allows you to change
the installation directory.

For example,

PUPPETEER_CACHE_DIR=$(pwd) npm install puppeteer
PUPPETEER_CACHE_DIR=$(pwd) node <script-path>

You can also create a configuration file named .puppeteerrc.cjs (or
puppeteer.config.cjs) at the root of your application with the contents

const {join} = require('path');

/**
 * @type {import("puppeteer").Configuration}
 */
module.exports = {
  cacheDirectory: join(__dirname, '.cache', 'puppeteer'),
};

You will need to reinstall puppeteer in order for the configuration to take
effect. See Configuring Puppeteer for more
information.

Chrome headless doesn’t launch on Windows

Some chrome policies might
enforce running Chrome/Chromium with certain extensions.

Puppeteer passes --disable-extensions flag by default and will fail to launch
when such policies are active.

To work around this, try running without the flag:

const browser = await puppeteer.launch({
  ignoreDefaultArgs: ['--disable-extensions'],
});

Context:
issue 3681.

Chrome headless doesn’t launch on UNIX

Make sure all the necessary dependencies are installed. You can run
ldd chrome | grep not on a Linux machine to check which dependencies are
missing. The common ones are provided below.

Debian (e.g. Ubuntu) Dependencies

ca-certificates
fonts-liberation
libasound2
libatk-bridge2.0-0
libatk1.0-0
libc6
libcairo2
libcups2
libdbus-1-3
libexpat1
libfontconfig1
libgbm1
libgcc1
libglib2.0-0
libgtk-3-0
libnspr4
libnss3
libpango-1.0-0
libpangocairo-1.0-0
libstdc++6
libx11-6
libx11-xcb1
libxcb1
libxcomposite1
libxcursor1
libxdamage1
libxext6
libxfixes3
libxi6
libxrandr2
libxrender1
libxss1
libxtst6
lsb-release
wget
xdg-utils

CentOS Dependencies

alsa-lib.x86_64
atk.x86_64
cups-libs.x86_64
gtk3.x86_64
ipa-gothic-fonts
libXcomposite.x86_64
libXcursor.x86_64
libXdamage.x86_64
libXext.x86_64
libXi.x86_64
libXrandr.x86_64
libXScrnSaver.x86_64
libXtst.x86_64
pango.x86_64
xorg-x11-fonts-100dpi
xorg-x11-fonts-75dpi
xorg-x11-fonts-cyrillic
xorg-x11-fonts-misc
xorg-x11-fonts-Type1
xorg-x11-utils

After installing dependencies you need to update nss library using this
command

Check out discussions

  • #290 — Debian
    troubleshooting
  • #391 — CentOS
    troubleshooting
  • #379 — Alpine
    troubleshooting

Chrome headless disables GPU compositing

Chrome/Chromium requires --use-gl=egl to
enable GPU acceleration in headless mode.

const browser = await puppeteer.launch({
  headless: true,
  args: ['--use-gl=egl'],
});

Chrome is downloaded but fails to launch on Node.js 14

If you get an error that looks like this when trying to launch Chromium:

(node:15505) UnhandledPromiseRejectionWarning: Error: Failed to launch the browser process!
spawn /Users/.../node_modules/puppeteer/.local-chromium/mac-756035/chrome-mac/Chromium.app/Contents/MacOS/Chromium ENOENT

This means that the browser was downloaded but failed to be extracted correctly.
The most common cause is a bug in Node.js v14.0.0 which broke extract-zip, the
module Puppeteer uses to extract browser downloads into the right place. The bug
was fixed in Node.js v14.1.0, so please make sure you’re running that version or
higher.

Setting Up Chrome Linux Sandbox

In order to protect the host environment from untrusted web content, Chrome uses
multiple layers of sandboxing.
For this to work properly, the host should be configured first. If there’s no
good sandbox for Chrome to use, it will crash with the error
No usable sandbox!.

If you absolutely trust the content you open in Chrome, you can launch
Chrome with the --no-sandbox argument:

const browser = await puppeteer.launch({
  args: ['--no-sandbox', '--disable-setuid-sandbox'],
});

:::caution

Running without a sandbox is strongly discouraged. Consider configuring a
sandbox instead.

:::

There are 2 ways to configure a sandbox in Chromium.

[recommended] Enable user namespace cloning

User namespace cloning is only supported by modern kernels. Unprivileged user
namespaces are generally fine to enable, but in some cases they open up more
kernel attack surface for (unsandboxed) non-root processes to elevate to kernel
privileges.

sudo sysctl -w kernel.unprivileged_userns_clone=1

[alternative] Setup setuid sandbox

The setuid sandbox comes as a standalone executable and is located next to the
Chromium that Puppeteer downloads. It is fine to re-use the same sandbox
executable for different Chromium versions, so the following could be done only
once per host environment:

# cd to the downloaded instance
cd <project-dir-path>/node_modules/puppeteer/.local-chromium/linux-<revision>/chrome-linux/
sudo chown root:root chrome_sandbox
sudo chmod 4755 chrome_sandbox
# copy sandbox executable to a shared location
sudo cp -p chrome_sandbox /usr/local/sbin/chrome-devel-sandbox
# export CHROME_DEVEL_SANDBOX env variable
export CHROME_DEVEL_SANDBOX=/usr/local/sbin/chrome-devel-sandbox

You might want to export the CHROME_DEVEL_SANDBOX env variable by default. In
this case, add the following to the ~/.bashrc or .zshenv:

export CHROME_DEVEL_SANDBOX=/usr/local/sbin/chrome-devel-sandbox

Running Puppeteer on Travis CI

👋 We ran our tests for Puppeteer on Travis CI until v6.0.0 (when we’ve
migrated to GitHub Actions) — see our historical
.travis.yml (v5.5.0)
for reference.

Tips-n-tricks:

  • xvfb service should be launched in order
    to run Chromium in non-headless mode
  • Runs on Xenial Linux on Travis by default
  • Runs npm install by default
  • node_modules is cached by default

.travis.yml might look like this:

language: node_js
node_js: node
services: xvfb
script:
  - npm test

Running Puppeteer on WSL (Windows subsystem for Linux)

See this thread with some
tips specific to WSL. In a nutshell, you need to install missing dependencies by
either:

  1. Installing Chrome on WSL to install all dependencies
  2. Installing required dependencies manually:
    sudo apt install libgtk-3-dev libnotify-dev libgconf-2-4 libnss3 libxss1 libasound2.

:::caution

The list of required dependencies might get outdated and depend on what you
already have installed.

:::

Running Puppeteer on CircleCI

Running Puppeteer smoothly on CircleCI requires the following steps:

  1. Start with a
    NodeJS image in your
    config like so:

    docker:
  - image: circleci/node:14 # Use your desired version
    environment:
      NODE_ENV: development # Only needed if puppeteer is in `devDependencies`
  2. Dependencies like libXtst6 probably need to be installed via apt-get, so
    use the
    threetreeslight/puppeteer
    orb
    (instructions),
    or paste parts of its
    source
    into your own config.
  3. Lastly, if you’re using Puppeteer through Jest, then you may encounter an
    error spawning child processes:

    [00:00.0]  jest args: --e2e --spec --max-workers=36
Error: spawn ENOMEM
   at ChildProcess.spawn (internal/child_process.js:394:11)

    This is likely caused by Jest autodetecting the number of processes on the
    entire machine (36) rather than the number allowed to your container (2).
    To fix this, set jest --maxWorkers=2 in your test command.

Running Puppeteer in Docker

👋 We used Cirrus Ci to run our tests for Puppeteer
in a Docker container until v3.0.x — see our historical
Dockerfile.linux (v3.0.1)
for reference. Starting from v16.0.0 we are shipping a Docker image via the
GitHub registry. The Dockerfile is located
here and
the usage instructions are in the
README.md. The
instructions below might be still helpful if you are building your own image.

Getting headless Chrome up and running in Docker can be tricky. The bundled
Chromium that Puppeteer installs is missing the necessary shared library
dependencies.

To fix, you’ll need to install the missing dependencies and the latest Chromium
package in your Dockerfile:

FROM node:14-slim

# Install latest chrome dev package and fonts to support major charsets (Chinese, Japanese, Arabic, Hebrew, Thai and a few others)
# Note: this installs the necessary libs to make the bundled version of Chromium that Puppeteer
# installs, work.
RUN apt-get update 
    && apt-get install -y wget gnupg 
    && 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 fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst fonts-freefont-ttf libxss1 
      --no-install-recommends 
    && rm -rf /var/lib/apt/lists/*

# If running Docker >= 1.13.0 use docker run's --init arg to reap zombie processes, otherwise
# uncomment the following lines to have `dumb-init` as PID 1
# ADD https://github.com/Yelp/dumb-init/releases/download/v1.2.2/dumb-init_1.2.2_x86_64 /usr/local/bin/dumb-init
# RUN chmod +x /usr/local/bin/dumb-init
# ENTRYPOINT ["dumb-init", "--"]

# Uncomment to skip the chromium download when installing puppeteer. If you do,
# you'll need to launch puppeteer with:
#     browser.launch({executablePath: 'google-chrome-stable'})
# ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD true

# Install puppeteer so it's available in the container.
RUN npm init -y &&  
    npm i puppeteer 
    # Add user so we don't need --no-sandbox.
    # same layer as npm install to keep re-chowned files from using up several hundred MBs more space
    && groupadd -r pptruser && useradd -r -g pptruser -G audio,video pptruser 
    && mkdir -p /home/pptruser/Downloads 
    && chown -R pptruser:pptruser /home/pptruser 
    && chown -R pptruser:pptruser /node_modules 
    && chown -R pptruser:pptruser /package.json 
    && chown -R pptruser:pptruser /package-lock.json

# Run everything after as non-privileged user.
USER pptruser

CMD ["google-chrome-stable"]

Build the container:

docker build -t puppeteer-chrome-linux .

Run the container by passing node -e "<yourscript.js content as a string>" as
the command:

 docker run -i --init --rm --cap-add=SYS_ADMIN 
   --name puppeteer-chrome puppeteer-chrome-linux 
   node -e "`cat yourscript.js`"

There’s a full example at https://github.com/ebidel/try-puppeteer that shows how
to run this Dockerfile from a webserver running on App Engine Flex (Node).

Running on Alpine

The
newest Chromium package
supported on Alpine is 100, which corresponds to
Puppeteer v13.5.0.

Example Dockerfile:

FROM alpine

# Installs latest Chromium (100) package.
RUN apk add --no-cache 
      chromium 
      nss 
      freetype 
      harfbuzz 
      ca-certificates 
      ttf-freefont 
      nodejs 
      yarn

...

# Tell Puppeteer to skip installing Chrome. We'll be using the installed package.
ENV PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromium-browser

# Puppeteer v13.5.0 works with Chromium 100.
RUN yarn add puppeteer@13.5.0

# Add user so we don't need --no-sandbox.
RUN addgroup -S pptruser && adduser -S -G pptruser pptruser 
    && mkdir -p /home/pptruser/Downloads /app 
    && chown -R pptruser:pptruser /home/pptruser 
    && chown -R pptruser:pptruser /app

# Run everything after as non-privileged user.
USER pptruser

...

Running Puppeteer on GitlabCI

This is very similar to some of the instructions above, but require a bit
different configuration to finally achieve success.

Usually the issue looks like this:

Error: Failed to launch chrome! spawn /usr/bin/chromium-browser ENOENT

You need to patch two places:

  1. Your gitlab-ci.yml config
  2. Arguments’ list when launching pupepeteer

In gitlab-ci.yml we need to install some packages to make it possible to
launch headless Chrome in your docker env:

before_script:
  - apt-get update
  - apt-get install -yq gconf-service libasound2 libatk1.0-0 libc6 libcairo2
    libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgcc1 libgconf-2-4
    libgdk-pixbuf2.0-0 libglib2.0-0 libgtk-3-0 libnspr4 libpango-1.0-0
    libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1
    libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1
    libxss1 libxtst6 ca-certificates fonts-liberation libnss3 lsb-release
    xdg-utils wget

Next, you have to use '--no-sandbox' mode and also
'--disable-setuid-sandbox' when launching Puppeteer. This can be done by
passing them as an arguments to your .launch() call:
puppeteer.launch({ args: ['--no-sandbox', '--disable-setuid-sandbox'] });.

Tips

By default, Docker runs a container with a /dev/shm shared memory space 64MB.
This is typically too small
for Chrome and will cause Chrome to crash when rendering large pages. To fix,
run the container with docker run --shm-size=1gb to increase the size of
/dev/shm. Since Chrome 65, this is no longer necessary. Instead, launch the
browser with the --disable-dev-shm-usage flag:

const browser = await puppeteer.launch({
  args: ['--disable-dev-shm-usage'],
});

This will write shared memory files into /tmp instead of /dev/shm. See
crbug.com/736452
for more details.

Seeing other weird errors when launching Chrome? Try running your container with
docker run --cap-add=SYS_ADMIN when developing locally. Since the Dockerfile
adds a pptr user as a non-privileged user, it may not have all the necessary
privileges.

dumb-init is worth checking out if you’re
experiencing a lot of zombies Chrome processes sticking around. There’s special
treatment for processes with PID=1, which makes it hard to terminate Chrome
properly in some cases (e.g. in Docker).

Running Puppeteer in the cloud

Running Puppeteer on Google App Engine

The Node.js runtime of the
App Engine standard environment
comes with all system packages needed to run Headless Chrome.

To use puppeteer, simply list the module as a dependency in your
package.json and deploy to Google App Engine. Read more about using
puppeteer on App Engine by following
the official tutorial.

Running Puppeteer on Google Cloud Functions

You can try running Puppeteer on
Google Cloud Functions but we have
been getting reports that newest runtimes don’t have all dependencies to run
Chromium.

If you encounter problems due to missing Chromium dependencies, consider using
Google Cloud Run instead where you can provide a custom Dockerfile with all
dependencies. Also, see our
official Docker image.

Running Puppeteer on Google Cloud Run

The default Node.js runtime of
Google Cloud Run does not come with the
system packages needed to run Headless Chrome. You will need to set up your own
Dockerfile and
include the missing dependencies.

Running Puppeteer on Heroku

Running Puppeteer on Heroku requires some additional dependencies that aren’t
included on the Linux box that Heroku spins up for you. To add the dependencies
on deploy, add the Puppeteer Heroku buildpack to the list of buildpacks for your
app under Settings > Buildpacks.

The url for the buildpack is
https://github.com/jontewks/puppeteer-heroku-buildpack

Ensure that you’re using '--no-sandbox' mode when launching Puppeteer. This
can be done by passing it as an argument to your .launch() call:
puppeteer.launch({ args: ['--no-sandbox'] });.

When you click add buildpack, simply paste that url into the input, and click
save. On the next deploy, your app will also install the dependencies that
Puppeteer needs to run.

If you need to render Chinese, Japanese, or Korean characters you may need to
use a buildpack with additional font files like
https://github.com/CoffeeAndCode/puppeteer-heroku-buildpack

There’s also another
simple guide from @timleland
that includes a sample project:
https://timleland.com/headless-chrome-on-heroku/.

Running Puppeteer on AWS Lambda

AWS Lambda limits
deployment package sizes to ~50MB. This presents challenges for running headless
Chrome (and therefore Puppeteer) on Lambda. The community has put together a few
resources that work around the issues:

  • https://github.com/alixaxel/chrome-aws-lambda (kept updated with the latest
    stable release of puppeteer)
  • https://github.com/adieuadieu/serverless-chrome/blob/HEAD/docs/chrome.md
    (serverless plugin — outdated)

Running Puppeteer on AWS EC2 instance running Amazon-Linux

If you are using an EC2 instance running amazon-linux in your CI/CD pipeline,
and if you want to run Puppeteer tests in amazon-linux, follow these steps.

  1. To install Chromium, you have to first enable amazon-linux-extras which
    comes as part of
    EPEL (Extra Packages for Enterprise Linux):

    sudo amazon-linux-extras install epel -y

  2. Next, install Chromium:

    sudo yum install -y chromium

Now Puppeteer can launch Chromium to run your tests. If you do not enable EPEL
and if you continue installing chromium as part of npm install, Puppeteer
cannot launch Chromium due to unavailablity of libatk-1.0.so.0 and many more
packages.

Code Transpilation Issues

If you are using a JavaScript transpiler like babel or TypeScript, calling
evaluate() with an async function might not work. This is because while
puppeteer uses Function.prototype.toString() to serialize functions while
transpilers could be changing the output code in such a way it’s incompatible
with puppeteer.

Some workarounds to this problem would be to instruct the transpiler not to mess
up with the code, for example, configure TypeScript to use latest ecma version
("target": "es2018"). Another workaround could be using string templates
instead of functions:

await page.evaluate(`(async() => {
   console.log('1');
})()`);
Источник

Chrome headless doesn’t launch on Windows

Some chrome policies might enforce running Chrome/Chromium with certain extensions.

Puppeteer passes --disable-extensions flag by default and will fail to launch when such policies are active.

To work around this, try running without the flag:

const browser = await puppeteer.launch({
  ignoreDefaultArgs: ['--disable-extensions'],
});

Context: issue 3681.

Chrome headless doesn’t launch on UNIX

Make sure all the necessary dependencies are installed. You can run ldd chrome | grep not on a Linux machine to check which dependencies are missing. The common ones are provided below.

Debian (e.g. Ubuntu) Dependencies

ca-certificates
fonts-liberation
libappindicator3-1
libasound2
libatk-bridge2.0-0
libatk1.0-0
libc6
libcairo2
libcups2
libdbus-1-3
libexpat1
libfontconfig1
libgbm1
libgcc1
libglib2.0-0
libgtk-3-0
libnspr4
libnss3
libpango-1.0-0
libpangocairo-1.0-0
libstdc++6
libx11-6
libx11-xcb1
libxcb1
libxcomposite1
libxcursor1
libxdamage1
libxext6
libxfixes3
libxi6
libxrandr2
libxrender1
libxss1
libxtst6
lsb-release
wget
xdg-utils

CentOS Dependencies

alsa-lib.x86_64
atk.x86_64
cups-libs.x86_64
gtk3.x86_64
ipa-gothic-fonts
libXcomposite.x86_64
libXcursor.x86_64
libXdamage.x86_64
libXext.x86_64
libXi.x86_64
libXrandr.x86_64
libXScrnSaver.x86_64
libXtst.x86_64
pango.x86_64
xorg-x11-fonts-100dpi
xorg-x11-fonts-75dpi
xorg-x11-fonts-cyrillic
xorg-x11-fonts-misc
xorg-x11-fonts-Type1
xorg-x11-utils

After installing dependencies you need to update nss library using this command

yum update nss -y

Check out discussions

  • #290 — Debian troubleshooting
  • #391 — CentOS troubleshooting
  • #379 — Alpine troubleshooting

Chrome headless disables GPU compositing

Chrome/Chromium requires --use-gl=egl to enable GPU acceleration in headless mode.

const browser = await puppeteer.launch({
  headless: true,
  args: ['--use-gl=egl'],
});

Chrome is downloaded but fails to launch on Node.js 14

If you get an error that looks like this when trying to launch Chromium:

(node:15505) UnhandledPromiseRejectionWarning: Error: Failed to launch the browser process!
spawn /Users/.../node_modules/puppeteer/.local-chromium/mac-756035/chrome-mac/Chromium.app/Contents/MacOS/Chromium ENOENT

This means that the browser was downloaded but failed to be extracted correctly. The most common cause is a bug in Node.js v14.0.0 which broke extract-zip, the module Puppeteer uses to extract browser downloads into the right place. The bug was fixed in Node.js v14.1.0, so please make sure you’re running that version or higher.

Setting Up Chrome Linux Sandbox

In order to protect the host environment from untrusted web content, Chrome uses multiple layers of sandboxing. For this to work properly, the host should be configured first. If there’s no good sandbox for Chrome to use, it will crash with the error No usable sandbox!.

If you absolutely trust the content you open in Chrome, you can launch Chrome with the --no-sandbox argument:

const browser = await puppeteer.launch({
  args: ['--no-sandbox', '--disable-setuid-sandbox'],
});

Running without a sandbox is strongly discouraged. Consider configuring a sandbox instead.

There are 2 ways to configure a sandbox in Chromium.

[recommended] Enable user namespace cloning

User namespace cloning is only supported by modern kernels. Unprivileged user namespaces are generally fine to enable, but in some cases they open up more kernel attack surface for (unsandboxed) non-root processes to elevate to kernel privileges.

sudo sysctl -w kernel.unprivileged_userns_clone=1

[alternative] Setup setuid sandbox

The setuid sandbox comes as a standalone executable and is located next to the Chromium that Puppeteer downloads. It is fine to re-use the same sandbox executable for different Chromium versions, so the following could be done only once per host environment:

# cd to the downloaded instance
cd <project-dir-path>/node_modules/puppeteer/.local-chromium/linux-<revision>/chrome-linux/
sudo chown root:root chrome_sandbox
sudo chmod 4755 chrome_sandbox
# copy sandbox executable to a shared location
sudo cp -p chrome_sandbox /usr/local/sbin/chrome-devel-sandbox
# export CHROME_DEVEL_SANDBOX env variable
export CHROME_DEVEL_SANDBOX=/usr/local/sbin/chrome-devel-sandbox

You might want to export the CHROME_DEVEL_SANDBOX env variable by default. In this case, add the following to the ~/.bashrc or .zshenv:

export CHROME_DEVEL_SANDBOX=/usr/local/sbin/chrome-devel-sandbox

Running Puppeteer on Travis CI

👋 We ran our tests for Puppeteer on Travis CI until v6.0.0 (when we’ve migrated to GitHub Actions) — see our historical .travis.yml (v5.5.0) for reference.

Tips-n-tricks:

  • xvfb service should be launched in order to run Chromium in non-headless mode
  • Runs on Xenial Linux on Travis by default
  • Runs npm install by default
  • node_modules is cached by default

.travis.yml might look like this:

language: node_js
node_js: node
services: xvfb
script:
  - npm run test

Running Puppeteer on CircleCI

Running Puppeteer smoothly on CircleCI requires the following steps:

  1. Start with a NodeJS image in your config like so: 
    docker:
      - image: circleci/node:14 # Use your desired version
        environment:
          NODE_ENV: development # Only needed if puppeteer is in `devDependencies`
  2. Dependencies like libXtst6 probably need to be installed via apt-get, so use the threetreeslight/puppeteer orb (instructions), or paste parts of its source into your own config.
  3. Lastly, if you’re using Puppeteer through Jest, then you may encounter an error spawning child processes: 
    [00:00.0]  jest args: --e2e --spec --max-workers=36
    Error: spawn ENOMEM
       at ChildProcess.spawn (internal/child_process.js:394:11)

    This is likely caused by Jest autodetecting the number of processes on the entire machine (36) rather than the number allowed to your container (2). To fix this, set jest --maxWorkers=2 in your test command.

Running Puppeteer in Docker

We used Cirrus Ci to run our tests for Puppeteer in a Docker container until v3.0.x — see our historical Dockerfile.linux (v3.0.1) for reference.

Getting headless Chrome up and running in Docker can be tricky. The bundled Chromium that Puppeteer installs is missing the necessary shared library dependencies.

To fix, you’ll need to install the missing dependencies and the latest Chromium package in your Dockerfile:

FROM node:14-slim
# Install latest chrome dev package and fonts to support major charsets (Chinese, Japanese, Arabic, Hebrew, Thai and a few others)
# Note: this installs the necessary libs to make the bundled version of Chromium that Puppeteer
# installs, work.
RUN apt-get update 
    && apt-get install -y wget gnupg 
    && 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 fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst fonts-freefont-ttf libxss1 
      --no-install-recommends 
    && rm -rf /var/lib/apt/lists/*
# If running Docker >= 1.13.0 use docker run's --init arg to reap zombie processes, otherwise
# uncomment the following lines to have `dumb-init` as PID 1
# ADD https://github.com/Yelp/dumb-init/releases/download/v1.2.2/dumb-init_1.2.2_x86_64 /usr/local/bin/dumb-init
# RUN chmod +x /usr/local/bin/dumb-init
# ENTRYPOINT ["dumb-init", "--"]
# Uncomment to skip the chromium download when installing puppeteer. If you do,
# you'll need to launch puppeteer with:
#     browser.launch({executablePath: 'google-chrome-stable'})
# ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD true
# Install puppeteer so it's available in the container.
RUN npm init -y &&  
    npm i puppeteer 
    # Add user so we don't need --no-sandbox.
    # same layer as npm install to keep re-chowned files from using up several hundred MBs more space
    && groupadd -r pptruser && useradd -r -g pptruser -G audio,video pptruser 
    && mkdir -p /home/pptruser/Downloads 
    && chown -R pptruser:pptruser /home/pptruser 
    && chown -R pptruser:pptruser /node_modules 
    && chown -R pptruser:pptruser /package.json 
    && chown -R pptruser:pptruser /package-lock.json





  



                       
  





# Run everything after as non-privileged user.
USER pptruser
CMD ["google-chrome-stable"]

Build the container:

docker build -t puppeteer-chrome-linux .

Run the container by passing node -e "<yourscript.js content as a string>" as the command:

 docker run -i --init --rm --cap-add=SYS_ADMIN 
   --name puppeteer-chrome puppeteer-chrome-linux 
   node -e "`cat yourscript.js`"

There’s a full example at https://github.com/ebidel/try-puppeteer that shows how to run this Dockerfile from a webserver running on App Engine Flex (Node).

Running on Alpine

The newest Chromium package supported on Alpine is 100, which corresponds to Puppeteer v13.5.0.

Example Dockerfile:

FROM alpine
# Installs latest Chromium (100) package.
RUN apk add --no-cache 
      chromium 
      nss 
      freetype 
      harfbuzz 
      ca-certificates 
      ttf-freefont 
      nodejs 
      yarn
...
# Tell Puppeteer to skip installing Chrome. We'll be using the installed package.
ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true 
    PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromium-browser





  



                       
  





# Puppeteer v13.5.0 works with Chromium 100.
RUN yarn add puppeteer@13.5.0
# Add user so we don't need --no-sandbox.
RUN addgroup -S pptruser && adduser -S -G pptruser pptruser 
    && mkdir -p /home/pptruser/Downloads /app 
    && chown -R pptruser:pptruser /home/pptruser 
    && chown -R pptruser:pptruser /app
# Run everything after as non-privileged user.
USER pptruser
...

Tips

By default, Docker runs a container with a /dev/shm shared memory space 64MB. This is typically too small for Chrome and will cause Chrome to crash when rendering large pages. To fix, run the container with docker run --shm-size=1gb to increase the size of /dev/shm. Since Chrome 65, this is no longer necessary. Instead, launch the browser with the --disable-dev-shm-usage flag:

const browser = await puppeteer.launch({
  args: ['--disable-dev-shm-usage'],
});

This will write shared memory files into /tmp instead of /dev/shm. See crbug.com/736452 for more details.

Seeing other weird errors when launching Chrome? Try running your container with docker run --cap-add=SYS_ADMIN when developing locally. Since the Dockerfile adds a pptr user as a non-privileged user, it may not have all the necessary privileges.

dumb-init is worth checking out if you’re experiencing a lot of zombies Chrome processes sticking around. There’s special treatment for processes with PID=1, which makes it hard to terminate Chrome properly in some cases (e.g. in Docker).

Running Puppeteer in the cloud

Running Puppeteer on Google App Engine

The Node.js runtime of the App Engine standard environment comes with all system packages needed to run Headless Chrome.

To use puppeteer, simply list the module as a dependency in your package.json and deploy to Google App Engine. Read more about using puppeteer on App Engine by following the official tutorial.

Running Puppeteer on Google Cloud Functions

The Node.js 10 runtime of Google Cloud Functions comes with all system packages needed to run Headless Chrome.

To use puppeteer, simply list the module as a dependency in your package.json and deploy your function to Google Cloud Functions using the nodejs10 runtime.

Running Puppeteer on Google Cloud Run

The default Node.js runtime of Google Cloud Run does not come with the system packages needed to run Headless Chrome. You will need to set up your own Dockerfile and include the missing dependencies.

Running Puppeteer on Heroku

Running Puppeteer on Heroku requires some additional dependencies that aren’t included on the Linux box that Heroku spins up for you. To add the dependencies on deploy, add the Puppeteer Heroku buildpack to the list of buildpacks for your app under Settings > Buildpacks.

The url for the buildpack is https://github.com/jontewks/puppeteer-heroku-buildpack

Ensure that you’re using '--no-sandbox' mode when launching Puppeteer. This can be done by passing it as an argument to your .launch() call: puppeteer.launch({ args: ['--no-sandbox'] });.

When you click add buildpack, simply paste that url into the input, and click save. On the next deploy, your app will also install the dependencies that Puppeteer needs to run.

If you need to render Chinese, Japanese, or Korean characters you may need to use a buildpack with additional font files like https://github.com/CoffeeAndCode/puppeteer-heroku-buildpack

There’s also another simple guide from @timleland that includes a sample project: https://timleland.com/headless-chrome-on-heroku/.

Running Puppeteer on AWS Lambda

AWS Lambda limits deployment package sizes to ~50MB. This presents challenges for running headless Chrome (and therefore Puppeteer) on Lambda. The community has put together a few resources that work around the issues:

  • https://github.com/alixaxel/chrome-aws-lambda (kept updated with the latest stable release of puppeteer)
  • https://github.com/adieuadieu/serverless-chrome/blob/HEAD/docs/chrome.md (serverless plugin — outdated)

Running Puppeteer on AWS EC2 instance running Amazon-Linux

If you are using an EC2 instance running amazon-linux in your CI/CD pipeline, and if you want to run Puppeteer tests in amazon-linux, follow these steps.

  1. To install Chromium, you have to first enable amazon-linux-extras which comes as part of EPEL (Extra Packages for Enterprise Linux):

    sudo amazon-linux-extras install epel -y

  2. Next, install Chromium:

    sudo yum install -y chromium

Now Puppeteer can launch Chromium to run your tests. If you do not enable EPEL and if you continue installing chromium as part of npm install, Puppeteer cannot launch Chromium due to unavailablity of libatk-1.0.so.0 and many more packages.

Code Transpilation Issues

If you are using a JavaScript transpiler like babel or TypeScript, calling evaluate() with an async function might not work. This is because while puppeteer uses Function.prototype.toString() to serialize functions while transpilers could be changing the output code in such a way it’s incompatible with puppeteer.

Some workarounds to this problem would be to instruct the transpiler not to mess up with the code, for example, configure TypeScript to use latest ecma version ("target": "es2018"). Another workaround could be using string templates instead of functions:

await page.evaluate(`(async() => {
   console.log('1');
})()`);
Источник

Содержание

  1. [Bug]: Failed to launch the browser process! #8135
  2. Comments
  3. Bug description
  4. Troubleshooting
  5. # Chrome headless doesn’t launch on Windows
  6. # Chrome headless doesn’t launch on UNIX
  7. # Chrome headless disables GPU compositing
  8. # Chrome is downloaded but fails to launch on Node.js 14
  9. # Setting Up Chrome Linux Sandbox
  10. # [recommended] Enable user namespace cloning
  11. # [alternative] Setup setuid sandbox
  12. # Running Puppeteer on Travis CI
  13. # Running Puppeteer on CircleCI
  14. # Running Puppeteer in Docker
  15. # Running on Alpine
  16. # Running Puppeteer in the cloud
  17. # Running Puppeteer on Google App Engine
  18. # Running Puppeteer on Google Cloud Functions
  19. # Running Puppeteer on Google Cloud Run
  20. # Running Puppeteer on Heroku
  21. # Running Puppeteer on AWS Lambda
  22. # Running Puppeteer on AWS EC2 instance running Amazon-Linux
  23. # Code Transpilation Issues
  24. Name already in use
  25. puppeteer / docs / troubleshooting.md
  26. Users who have contributed to this file

[Bug]: Failed to launch the browser process! #8135

Bug description

Steps to reproduce the problem:
I am having difficulty running puppeteer functions . I keep getting this error —
(node:13460) UnhandledPromiseRejectionWarning: Error: Failed to launch the browser process!
/node_modules/puppeteer/.local-chromium/linux-970485/chrome-linux/chrome: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory

at onClose (/node_modules/puppeteer/lib/cjs/puppeteer/node/BrowserRunner.js:237:20)
at Interface.helper_js_1.helper.addEventListener (/node_modules/puppeteer/lib/cjs/puppeteer/node/BrowserRunner.js:227:68)
at Interface.emit (events.js:203:15)
at Interface.close (readline.js:397:8)
at Socket.onend (readline.js:173:10)
at Socket.emit (events.js:203:15)
at endReadableNT (_stream_readable.js:1145:12)
at process._tickCallback (internal/process/next_tick.js:63:19)
(node:13460) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:13460) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I have tried installing all dependencies and all 1000 resolutions to disable sandbox and what not but no luck , i will be really glad if you can help me out with this error resolution.

Источник

Troubleshooting

Published on Thursday, January 11, 2018 • Updated on Thursday, June 16, 2022

# Chrome headless doesn’t launch on Windows

Some chrome policies might enforce running Chrome/Chromium with certain extensions.

Puppeteer passes —disable-extensions flag by default and will fail to launch when such policies are active.

To work around this, try running without the flag:

# Chrome headless doesn’t launch on UNIX

Make sure all the necessary dependencies are installed. You can run ldd chrome | grep not on a Linux machine to check which dependencies are missing. The common ones are provided below.

Debian (e.g. Ubuntu) Dependencies CentOS Dependencies

After installing dependencies you need to update nss library using this command

Check out discussions

  • #290 — Debian troubleshooting
  • #391 — CentOS troubleshooting
  • #379 — Alpine troubleshooting

# Chrome headless disables GPU compositing

# Chrome is downloaded but fails to launch on Node.js 14

If you get an error that looks like this when trying to launch Chromium:

This means that the browser was downloaded but failed to be extracted correctly. The most common cause is a bug in Node.js v14.0.0 which broke extract-zip , the module Puppeteer uses to extract browser downloads into the right place. The bug was fixed in Node.js v14.1.0, so please make sure you’re running that version or higher.

# Setting Up Chrome Linux Sandbox

In order to protect the host environment from untrusted web content, Chrome uses multiple layers of sandboxing. For this to work properly, the host should be configured first. If there’s no good sandbox for Chrome to use, it will crash with the error No usable sandbox! .

If you absolutely trust the content you open in Chrome, you can launch Chrome with the —no-sandbox argument:

Running without a sandbox is strongly discouraged. Consider configuring a sandbox instead.

There are 2 ways to configure a sandbox in Chromium.

# [recommended] Enable user namespace cloning

User namespace cloning is only supported by modern kernels. Unprivileged user namespaces are generally fine to enable, but in some cases they open up more kernel attack surface for (unsandboxed) non-root processes to elevate to kernel privileges.

# [alternative] Setup setuid sandbox

The setuid sandbox comes as a standalone executable and is located next to the Chromium that Puppeteer downloads. It is fine to re-use the same sandbox executable for different Chromium versions, so the following could be done only once per host environment:

You might want to export the CHROME_DEVEL_SANDBOX env variable by default. In this case, add the following to the

/.bashrc or .zshenv :

# Running Puppeteer on Travis CI

👋 We ran our tests for Puppeteer on Travis CI until v6.0.0 (when we’ve migrated to GitHub Actions) — see our historical .travis.yml (v5.5.0) for reference.

  • xvfb service should be launched in order to run Chromium in non-headless mode
  • Runs on Xenial Linux on Travis by default
  • Runs npm install by default
  • node_modules is cached by default

.travis.yml might look like this:

# Running Puppeteer on CircleCI

Running Puppeteer smoothly on CircleCI requires the following steps:

  1. Start with a NodeJS image in your config like so:
  2. Dependencies like libXtst6 probably need to be installed via apt-get , so use the threetreeslight/puppeteer orb (instructions), or paste parts of its source into your own config.
  3. Lastly, if you’re using Puppeteer through Jest, then you may encounter an error spawning child processes:This is likely caused by Jest autodetecting the number of processes on the entire machine ( 36 ) rather than the number allowed to your container ( 2 ). To fix this, set jest —maxWorkers=2 in your test command.

# Running Puppeteer in Docker

We used Cirrus Ci to run our tests for Puppeteer in a Docker container until v3.0.x — see our historical Dockerfile.linux (v3.0.1) for reference.

Getting headless Chrome up and running in Docker can be tricky. The bundled Chromium that Puppeteer installs is missing the necessary shared library dependencies.

To fix, you’ll need to install the missing dependencies and the latest Chromium package in your Dockerfile:

Build the container:

Run the container by passing node -e » » as the command:

There’s a full example at https://github.com/ebidel/try-puppeteer that shows how to run this Dockerfile from a webserver running on App Engine Flex (Node).

# Running on Alpine

The newest Chromium package supported on Alpine is 100, which corresponds to Puppeteer v13.5.0.

By default, Docker runs a container with a /dev/shm shared memory space 64MB. This is typically too small for Chrome and will cause Chrome to crash when rendering large pages. To fix, run the container with docker run —shm-size=1gb to increase the size of /dev/shm . Since Chrome 65, this is no longer necessary. Instead, launch the browser with the —disable-dev-shm-usage flag:

This will write shared memory files into /tmp instead of /dev/shm . See crbug.com/736452 for more details.

Seeing other weird errors when launching Chrome? Try running your container with docker run —cap-add=SYS_ADMIN when developing locally. Since the Dockerfile adds a pptr user as a non-privileged user, it may not have all the necessary privileges.

dumb-init is worth checking out if you’re experiencing a lot of zombies Chrome processes sticking around. There’s special treatment for processes with PID=1, which makes it hard to terminate Chrome properly in some cases (e.g. in Docker).

# Running Puppeteer in the cloud

# Running Puppeteer on Google App Engine

The Node.js runtime of the App Engine standard environment comes with all system packages needed to run Headless Chrome.

To use puppeteer , simply list the module as a dependency in your package.json and deploy to Google App Engine. Read more about using puppeteer on App Engine by following the official tutorial.

# Running Puppeteer on Google Cloud Functions

The Node.js 10 runtime of Google Cloud Functions comes with all system packages needed to run Headless Chrome.

To use puppeteer , simply list the module as a dependency in your package.json and deploy your function to Google Cloud Functions using the nodejs10 runtime.

# Running Puppeteer on Google Cloud Run

The default Node.js runtime of Google Cloud Run does not come with the system packages needed to run Headless Chrome. You will need to set up your own Dockerfile and include the missing dependencies.

# Running Puppeteer on Heroku

Running Puppeteer on Heroku requires some additional dependencies that aren’t included on the Linux box that Heroku spins up for you. To add the dependencies on deploy, add the Puppeteer Heroku buildpack to the list of buildpacks for your app under Settings > Buildpacks.

The url for the buildpack is https://github.com/jontewks/puppeteer-heroku-buildpack

Ensure that you’re using ‘—no-sandbox’ mode when launching Puppeteer. This can be done by passing it as an argument to your .launch() call: puppeteer.launch(< args: [‘—no-sandbox’] >); .

When you click add buildpack, simply paste that url into the input, and click save. On the next deploy, your app will also install the dependencies that Puppeteer needs to run.

If you need to render Chinese, Japanese, or Korean characters you may need to use a buildpack with additional font files like https://github.com/CoffeeAndCode/puppeteer-heroku-buildpack

There’s also another simple guide from @timleland that includes a sample project: https://timleland.com/headless-chrome-on-heroku/.

# Running Puppeteer on AWS Lambda

AWS Lambda limits deployment package sizes to

50MB. This presents challenges for running headless Chrome (and therefore Puppeteer) on Lambda. The community has put together a few resources that work around the issues:

  • https://github.com/alixaxel/chrome-aws-lambda (kept updated with the latest stable release of puppeteer)
  • https://github.com/adieuadieu/serverless-chrome/blob/HEAD/docs/chrome.md (serverless plugin — outdated)

# Running Puppeteer on AWS EC2 instance running Amazon-Linux

If you are using an EC2 instance running amazon-linux in your CI/CD pipeline, and if you want to run Puppeteer tests in amazon-linux, follow these steps.

To install Chromium, you have to first enable amazon-linux-extras which comes as part of EPEL (Extra Packages for Enterprise Linux):

Next, install Chromium:

Now Puppeteer can launch Chromium to run your tests. If you do not enable EPEL and if you continue installing chromium as part of npm install , Puppeteer cannot launch Chromium due to unavailablity of libatk-1.0.so.0 and many more packages.

# Code Transpilation Issues

If you are using a JavaScript transpiler like babel or TypeScript, calling evaluate() with an async function might not work. This is because while puppeteer uses Function.prototype.toString() to serialize functions while transpilers could be changing the output code in such a way it’s incompatible with puppeteer .

Some workarounds to this problem would be to instruct the transpiler not to mess up with the code, for example, configure TypeScript to use latest ecma version ( «target»: «es2018» ). Another workaround could be using string templates instead of functions:

Updated on Thursday, June 16, 2022 • Improve article

Источник

Name already in use

puppeteer / docs / troubleshooting.md

  • Go to file T
  • Go to line L
  • Copy path
  • Copy permalink

68 contributors

Users who have contributed to this file

Copy raw contents

Copy raw contents

Chromium currently does not provide arm64 binaries for Linux. There are only binaries for Mac ARM with experimental support from Puppeteer.

Cannot find module ‘puppeteer-core/internal/. ‘

This can occur is your Node.js version is lower than 14 or you are using a custom resolver (such as jest-resolve ). For the former, we do not support deprecated versions of Node.js. For the latter, usually upgrading the resolver (or its parent module such as jest ) will work (e.g. #9121)

Could not find expected browser locally

Starting from v19.0.0, Puppeteer will download browsers into

/.cache/puppeteer using os.homedir for better caching between Puppeteer upgrades. Generally the home directory is well-defined (even on Windows), but occasionally the home directory may not be available. In this case, we provide the PUPPETEER_CACHE_DIR variable which allows you to change the installation directory.

You can also create a configuration file named .puppeteerrc.cjs (or puppeteer.config.cjs ) at the root of your application with the contents

You will need to reinstall puppeteer in order for the configuration to take effect. See Configuring Puppeteer for more information.

Chrome headless doesn’t launch on Windows

Some chrome policies might enforce running Chrome/Chromium with certain extensions.

Puppeteer passes —disable-extensions flag by default and will fail to launch when such policies are active.

To work around this, try running without the flag:

Chrome headless doesn’t launch on UNIX

Make sure all the necessary dependencies are installed. You can run ldd chrome | grep not on a Linux machine to check which dependencies are missing. The common ones are provided below.

Debian (e.g. Ubuntu) Dependencies

After installing dependencies you need to update nss library using this command

Chrome headless disables GPU compositing

Chrome is downloaded but fails to launch on Node.js 14

If you get an error that looks like this when trying to launch Chromium:

This means that the browser was downloaded but failed to be extracted correctly. The most common cause is a bug in Node.js v14.0.0 which broke extract-zip , the module Puppeteer uses to extract browser downloads into the right place. The bug was fixed in Node.js v14.1.0, so please make sure you’re running that version or higher.

Setting Up Chrome Linux Sandbox

In order to protect the host environment from untrusted web content, Chrome uses multiple layers of sandboxing. For this to work properly, the host should be configured first. If there’s no good sandbox for Chrome to use, it will crash with the error No usable sandbox! .

If you absolutely trust the content you open in Chrome, you can launch Chrome with the —no-sandbox argument:

Running without a sandbox is strongly discouraged. Consider configuring a sandbox instead.

There are 2 ways to configure a sandbox in Chromium.

User namespace cloning is only supported by modern kernels. Unprivileged user namespaces are generally fine to enable, but in some cases they open up more kernel attack surface for (unsandboxed) non-root processes to elevate to kernel privileges.

The setuid sandbox comes as a standalone executable and is located next to the Chromium that Puppeteer downloads. It is fine to re-use the same sandbox executable for different Chromium versions, so the following could be done only once per host environment:

You might want to export the CHROME_DEVEL_SANDBOX env variable by default. In this case, add the following to the

/.bashrc or .zshenv :

Running Puppeteer on Travis CI

👋 We ran our tests for Puppeteer on Travis CI until v6.0.0 (when we’ve migrated to GitHub Actions) — see our historical .travis.yml (v5.5.0) for reference.

  • xvfb service should be launched in order to run Chromium in non-headless mode
  • Runs on Xenial Linux on Travis by default
  • Runs npm install by default
  • node_modules is cached by default

.travis.yml might look like this:

Running Puppeteer on WSL (Windows subsystem for Linux)

See this thread with some tips specific to WSL. In a nutshell, you need to install missing dependencies by either:

  1. Installing Chrome on WSL to install all dependencies
  2. Installing required dependencies manually: sudo apt install libgtk-3-dev libnotify-dev libgconf-2-4 libnss3 libxss1 libasound2 .

The list of required dependencies might get outdated and depend on what you already have installed.

Running Puppeteer on CircleCI

Running Puppeteer smoothly on CircleCI requires the following steps:

    Start with a NodeJS image in your config like so:

Running Puppeteer in Docker

👋 We used Cirrus Ci to run our tests for Puppeteer in a Docker container until v3.0.x — see our historical Dockerfile.linux (v3.0.1) for reference. Starting from v16.0.0 we are shipping a Docker image via the GitHub registry. The Dockerfile is located here and the usage instructions are in the README.md. The instructions below might be still helpful if you are building your own image.

Getting headless Chrome up and running in Docker can be tricky. The bundled Chromium that Puppeteer installs is missing the necessary shared library dependencies.

To fix, you’ll need to install the missing dependencies and the latest Chromium package in your Dockerfile:

Build the container:

Run the container by passing node -e » » as the command:

There’s a full example at https://github.com/ebidel/try-puppeteer that shows how to run this Dockerfile from a webserver running on App Engine Flex (Node).

Running on Alpine

The newest Chromium package supported on Alpine is 100, which corresponds to Puppeteer v13.5.0.

Running Puppeteer on GitlabCI

This is very similar to some of the instructions above, but require a bit different configuration to finally achieve success.

Usually the issue looks like this:

You need to patch two places:

  1. Your gitlab-ci.yml config
  2. Arguments’ list when launching pupepeteer

In gitlab-ci.yml we need to install some packages to make it possible to launch headless Chrome in your docker env:

Next, you have to use ‘—no-sandbox’ mode and also ‘—disable-setuid-sandbox’ when launching Puppeteer. This can be done by passing them as an arguments to your .launch() call: puppeteer.launch(< args: [‘—no-sandbox’, ‘—disable-setuid-sandbox’] >); .

By default, Docker runs a container with a /dev/shm shared memory space 64MB. This is typically too small for Chrome and will cause Chrome to crash when rendering large pages. To fix, run the container with docker run —shm-size=1gb to increase the size of /dev/shm . Since Chrome 65, this is no longer necessary. Instead, launch the browser with the —disable-dev-shm-usage flag:

This will write shared memory files into /tmp instead of /dev/shm . See crbug.com/736452 for more details.

Seeing other weird errors when launching Chrome? Try running your container with docker run —cap-add=SYS_ADMIN when developing locally. Since the Dockerfile adds a pptr user as a non-privileged user, it may not have all the necessary privileges.

dumb-init is worth checking out if you’re experiencing a lot of zombies Chrome processes sticking around. There’s special treatment for processes with PID=1, which makes it hard to terminate Chrome properly in some cases (e.g. in Docker).

Running Puppeteer in the cloud

Running Puppeteer on Google App Engine

The Node.js runtime of the App Engine standard environment comes with all system packages needed to run Headless Chrome.

To use puppeteer , simply list the module as a dependency in your package.json and deploy to Google App Engine. Read more about using puppeteer on App Engine by following the official tutorial.

Running Puppeteer on Google Cloud Functions

The Node.js 10 runtime of Google Cloud Functions comes with all system packages needed to run Headless Chrome.

To use puppeteer , simply list the module as a dependency in your package.json and deploy your function to Google Cloud Functions using the nodejs10 runtime.

Running Puppeteer on Google Cloud Run

The default Node.js runtime of Google Cloud Run does not come with the system packages needed to run Headless Chrome. You will need to set up your own Dockerfile and include the missing dependencies.

Running Puppeteer on Heroku

Running Puppeteer on Heroku requires some additional dependencies that aren’t included on the Linux box that Heroku spins up for you. To add the dependencies on deploy, add the Puppeteer Heroku buildpack to the list of buildpacks for your app under Settings > Buildpacks.

Ensure that you’re using ‘—no-sandbox’ mode when launching Puppeteer. This can be done by passing it as an argument to your .launch() call: puppeteer.launch(< args: [‘—no-sandbox’] >); .

When you click add buildpack, simply paste that url into the input, and click save. On the next deploy, your app will also install the dependencies that Puppeteer needs to run.

If you need to render Chinese, Japanese, or Korean characters you may need to use a buildpack with additional font files like https://github.com/CoffeeAndCode/puppeteer-heroku-buildpack

There’s also another simple guide from @timleland that includes a sample project: https://timleland.com/headless-chrome-on-heroku/.

Running Puppeteer on AWS Lambda

AWS Lambda limits deployment package sizes to

50MB. This presents challenges for running headless Chrome (and therefore Puppeteer) on Lambda. The community has put together a few resources that work around the issues:

Running Puppeteer on AWS EC2 instance running Amazon-Linux

If you are using an EC2 instance running amazon-linux in your CI/CD pipeline, and if you want to run Puppeteer tests in amazon-linux, follow these steps.

To install Chromium, you have to first enable amazon-linux-extras which comes as part of EPEL (Extra Packages for Enterprise Linux):

Next, install Chromium:

Now Puppeteer can launch Chromium to run your tests. If you do not enable EPEL and if you continue installing chromium as part of npm install , Puppeteer cannot launch Chromium due to unavailablity of libatk-1.0.so.0 and many more packages.

Code Transpilation Issues

If you are using a JavaScript transpiler like babel or TypeScript, calling evaluate() with an async function might not work. This is because while puppeteer uses Function.prototype.toString() to serialize functions while transpilers could be changing the output code in such a way it’s incompatible with puppeteer .

Some workarounds to this problem would be to instruct the transpiler not to mess up with the code, for example, configure TypeScript to use latest ecma version ( «target»: «es2018» ). Another workaround could be using string templates instead of functions:

Источник

Источник

Reprinted: https://www.cnblogs.com/zhidong123/p/13345990.html

Recently, use the PuPpeteer plug-in to start Chrome failed, some systems can’t start evoch Chrome

I have a laptop installed 360 will be prompted, allowing execution to call success, company computer, no prompts can not start directly (company anti-virus software cannot be configured)

Console report error:

D:MyCodenode09puppetter> node .index.js       
(node:21488) UnhandledPromiseRejectionWarning: Error: Failed to launch the browser process! spawn D:MyCodenode09puppetternode_modules_puppeteer@5.2.1@puppeteer.local-chromiumwin64-782078chrome-winchrome.exe ENOENT


TROUBLESHOOTING: https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md

    at onClose (D:MyCodenode09puppetternode_modules_puppeteer@5.2.1@puppeteerlibcjspuppeteernodeBrowserRunner.js:193:20)        
    at ChildProcess.<anonymous> (D:MyCodenode09puppetternode_modules_puppeteer@5.2.1@puppeteerlibcjspuppeteernodeBrowserRunner.js:185:85)
    at ChildProcess.emit (events.js:315:20)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:274:12)
    at onErrorNT (internal/child_process.js:468:16)
    at processTicksAndRejections (internal/process/task_queues.js:84:21)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:21488) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rePS D:MyCodenode09puppetter> node .index.js       
(node:21488) UnhandledPromiseRejectionWarning: Error: Failed to launch the browser process! spawn D:MyCodenode09puppetternode_modules_puppeteer@5.2.1@puppeteer.local-chromiumwin64-782078chrome-winchrome.exe ENOENT


TROUBLESHOOTING: https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md

    at onClose (D:MyCodenode09puppetternode_modules_puppeteer@5.2.1@puppeteerlibcjspuppeteernodeBrowserRunner.js:193:20)        
    at ChildProcess.<anonymous> (D:MyCodenode09puppetternode_modules_puppeteer@5.2.1@puppeteerlibcjspuppeteernodeBrowserRunner.js:185:85)
    at ChildProcess.emit (events.js:315:20)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:274:12)
    at onErrorNT (internal/child_process.js:468:16)
    at processTicksAndRejections (internal/process/task_queues.js:84:21)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:21488) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:21488) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Later, I tried to find out

Forced to configure the Chrome path ExecutablePath and specify that you can open the browser effect headless, you can use it, if you do not allow your browser to visual, the page grabbing content will fail.

    let browser = await puppeteer.launch({ 
        executablePath: 'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe', 
        headless: false })
Источник

Понравилась статья? Поделить с друзьями:
  • Unhandled rejection error etelegram 400 bad request wrong file identifier http url specified
  • Unhandled rejection error etelegram 400 bad request message text is empty
  • Unhandled promise rejection syntaxerror json parse error unexpected identifier object
  • Unhandled php plugin error call the php plugin vendor
  • Unhandled exception произошла одна или несколько ошибок фазмофобия