This is working fine here on Elementary OS. I'm downloading a Debian installer now to try this out in a VM.

That's interesting. Could you please:

1. try launching chromium manually (chromium is downloaded at node_modules/puppeteer/.local-chromium)
2. if chromium launches for you, run the following (notice the added dumpio flag to the puppeteer.launch) and check what's in the stderr:

const puppeteer = require('puppeteer');
(async() => {
  const browser = await puppeteer.launch({dumpio: true});
  const page = await browser.newPage();
  await page.goto('https://example.com');
  await page.screenshot({path: 'example.png'});
  browser.close();
})();

Can't launch the local chrome:

% ~/p /home/fortes/p/node_modules/puppeteer/.local-chromium/linux-494755/chrome-linux/chrome --help
/home/fortes/p/node_modules/puppeteer/.local-chromium/linux-494755/chrome-linux/chrome: error while loading shared libraries: libX11-xcb.so.1: cannot open shared object file: No such file or directory

I should have mentioned that this is a headless machine that I'm ssh'd into. Given that this is for headless Chrome, I assume that scenario is still supported?

I think in the case of Debian systems you still need https://packages.debian.org/sid/libx11-xcb1 to run headless. That way the system has some of the API calls it needs to to do the rendering calculations.

Already have that installed, perhaps a different package is needed?

% ~/p sudo apt-get install libx11-xcb1
Reading package lists... Done
Building dependency tree
Reading state information... Done
libx11-xcb1 is already the newest version (2:1.6.4-3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

@fortes so do dependencies from #290 (comment) help?

I've installed those and can now run chrome --help. However, if I try to run chrome -v, I get the following:

febian:~/p /home/fortes/p/node_modules/puppeteer/.local-chromium/linux-494755/chrome-linux/chrome -v
[11104:11104:0816/105455.434188:FATAL:zygote_host_impl_linux.cc(123)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
#0 0x556f97804657 base::debug::StackTrace::StackTrace()
#1 0x556f97818311 logging::LogMessage::~LogMessage()
#2 0x556f96a091f1 content::ZygoteHostImpl::Init()
#3 0x556f966a3da0 content::BrowserMainLoop::EarlyInitialization()
#4 0x556f966aa4c3 content::BrowserMainRunnerImpl::Initialize()
#5 0x556f966a3532 content::BrowserMain()
#6 0x556f9750f7fd content::ContentMainRunnerImpl::Run()
#7 0x556f97517314 service_manager::Main()
#8 0x556f9750e462 content::ContentMain()
#9 0x556f9614eb74 ChromeMain
#10 0x7fa1f27c92b1 __libc_start_main
#11 0x556f9614e9d0 <unknown>

Received signal 6
#0 0x556f97804657 base::debug::StackTrace::StackTrace()
#1 0x556f978041cf base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7fa1f8b690c0 <unknown>
#3 0x7fa1f27dbfcf gsignal
#4 0x7fa1f27dd3fa abort
#5 0x556f97803202 base::debug::BreakDebugger()
#6 0x556f978187cc logging::LogMessage::~LogMessage()
#7 0x556f96a091f1 content::ZygoteHostImpl::Init()
#8 0x556f966a3da0 content::BrowserMainLoop::EarlyInitialization()
#9 0x556f966aa4c3 content::BrowserMainRunnerImpl::Initialize()
#10 0x556f966a3532 content::BrowserMain()
#11 0x556f9750f7fd content::ContentMainRunnerImpl::Run()
#12 0x556f97517314 service_manager::Main()
#13 0x556f9750e462 content::ContentMain()
#14 0x556f9614eb74 ChromeMain
#15 0x7fa1f27c92b1 __libc_start_main
#16 0x556f9614e9d0 <unknown>
  r8: 0000000000000000  r9: 00007fff8e2bda50 r10: 0000000000000008 r11: 0000000000000246
 r12: 00007fff8e2be160 r13: 000000000000016d r14: 00007fff8e2be158 r15: 00007fff8e2be150
  di: 0000000000000002  si: 00007fff8e2bda50  bp: 00007fff8e2bdd00  bx: 0000000000000006
  dx: 0000000000000000  ax: 0000000000000000  cx: 00007fa1f27dbfcf  sp: 00007fff8e2bdac8
  ip: 00007fa1f27dbfcf efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.

Check the sandbox docs linked to in that error and see if they can help you get it working. Either the security sandbox is messed up on Debian right now or something funky is happening to trigger it to need a non-kernel one. I'm looking into this once this VM server gets installed.

This should be solved with the '--no-sandbox' flag:

const puppeteer = require('puppeteer');
(async() => {
  const browser = await puppeteer.launch({args: ['--no-sandbox']});
  const page = await browser.newPage();
  await page.goto('https://example.com');
  await page.screenshot({path: 'example.png'});
  browser.close();
})();

It's worth considering adding both --no-sandbox --disable-setuid-sandbox to the default flags on linux.

In chrome-launcher/lighthouse we're already including --disable-setuid-sandbox and plan to add --no-sandbox soon for this reason.

I have always strongly urged people to never turn off the sandbox without a good cause, even in tests. It is a major part of the security system from what I understand.

I'm setting up a squeaky clean and fresh Debian VM to run some install steps in. We should be able to have it well documented how to get it operating without compromising system security.

I recall PHPStorm for example having an issue where it was serving on localhost, so a remote code execution exploit was opened up for any site including code that would look for the port in use and take advantage of a flaw in that server. Let's not open people up to security issues by disabling the sandbox here. Where they could be visiting any number of sites including code that looks for exploits to abuse.

Still no luck w/ those two flags:

febian:~/p /home/fortes/p/node_modules/puppeteer/.local-chromium/linux-494755/chrome-linux/chrome --no-sandbox --disable-setuid-sandbox

(chrome:12521): Gtk-WARNING **: cannot open display:
[0816/111850.260959:ERROR:nacl_helper_linux.cc(310)] NaCl helper process running without a sandbox!
Most likely you need to configure your SUID sandbox correctly

Same warning when just with --no-sandbox

Just as a quick update, I'm like 20-40ish minutes out from starting on testing the install procedure. Downloading packages now for a fresh net install of Debian 9. So, I should get back to you shortly with exact steps to reproduce. It just won't be as fast as something that doesn't require a full OS install.

Thanks for going through effort @Garbee! Will you be testing a headless Debian install, or using via ssh?

SSH is not relevant to the problem. Only a Debian server without any X/wayland system pre-installed (like any remote web server) will be enough to fully recreate the problem and steps to reproduce. So, that's what I'll be working with locally in a VM.

This may or may not be helpful...

I run Electron in a Docker instance on Docker Cloud.

I run this command:

xvfb-run -a --server-args="-screen 0 1024x1024x24" ./node_modules/.bin/electron ./index.js

and my Dockerfile contains the following commands to install dependencies:

RUN apt-get update -y -q
RUN apt-get install -y -q xvfb libgtk2.0-0 libxtst6 libxss1 libgconf-2-4 libnss3 libasound2

headless exists to not need xvfb to virtualize the X instance for Chrome. Since it is all done in software internally.

@Garbee awesome. This stuff isn't my strong suit.

I'm going to attempt to replace the Electron usage with puppeteer, so hopefully this will simplify our environment.

@fortes Are you running this as root by chance?

If you're running as root (after having all the required deps installed as listed earlier) you need to run without a sandbox since Chromium requires that (no clue why exactly yet.) If running as a normal user, then it should run just fine on a fresh debian install with the required dependencies.

Not running as root

That's interesting. I setup a fresh Linode box on Debian 9. Installed the packages listed above, then setup nodesource to install node 8. Then the yarn repository. New folder, yarn add puppeteer and then created the index.js and ran it. Everything works perfectly fine without a sandbox error.

Is the box you're running on under you complete control or is it someone else's like a VPS/shared host? If it is a remote host could you share the provider so I can look into if they do anything funny with their kernel configurations.

Ah yea, that's it. Your box host is messing you up. It has a very old Kernel. Debian 9 ships with 4.9.0-3 and you're running 3.14.0. So the security features of the kernel are extremely different. So, you may be in a case where you need to fallback to using the older file-based sandbox to have some level of security.

Although, in all honesty... Upgrade the kernel or get a host that doesn't keep you back. It's very important that the kernel gets updated for the best security and you're being left vulnerable.

@fortes If you could, please try running this script on your server to see if you have user namespacing enabled. https://gist.githubusercontent.com/Garbee/dfd33ba0a62f1cbc023b8d57de18efca/raw/f82ed513014062554a3536980a67390b57f1f858/user-namespace-check-linux.sh

for the dockerisers amongst us - i've launched successfully with this setup:

FROM node:8

RUN 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 libappindicator1 libnss3 lsb-release xdg-utils wget

RUN npm i puppeteer

RUN echo "\
const puppeteer = require('puppeteer');\n\
(async () => {\n\
  const browser = await puppeteer.launch({args: ['--no-sandbox', '--disable-setuid-sandbox']});\n\
  const page = await browser.newPage();\n\
  await page.goto('https://example.com');\n\
  await page.screenshot({path: 'example.png'});\n\
  browser.close();\n\
})();\
" > index.js

CMD ["node", "index.js"]

PR #311 is open to start looking at expanding the install script to make it much more interactive and friendly to help catch installation problems. You can check the code out from that PR and give it a spin. Please report on the PR of any problems you face or things you think could improve the flow.

Running into the problem using Windows Subsystem for Linux (WSL), as the "emulated" kernel doesn't support namespacing, and its not possible to upgrade the kernel. No combination of flags seemed to work, I switched to native Node.js on Windows and everything works fine.

I run into this problem trying to use puppeteer in Heroku

Don't use untrusted, prebuilt binaries. Use the trusted package from your distro:
https://packages.debian.org/stretch/chromium

Install it and then you can run chromium --headless. Puppeteer should also use it instead of bloating your home directory.

@orangecms currently puppeteer only runs with bleeding edge Chromium. Running against stable won't work at the moment.

Hmm that is unfortunate.

How about providing a Docker image or something like that with the correct libs preinstalled? Would that be feasible?

Addendum: Thanks a lot for the info @JoelEinbinder - I couldn't run it on my machine, either, so I installed =www-client/google-chrome-unstable-62.0.3178.0 (on Gentoo GNU/Linux). I am running a grsec kernel, which is known to break the Chrome sandbox.

So I pass options to launch():

const options = { executablePath: '/usr/bin/google-chrome-unstable' };
const browser = await puppeteer.launch(options);

I would add this to the docs, but I'm unsure where to put it. I just signed up for the CLA. Can anyone guide me there?

Using an external build is already detailed in the api docs and in the main README under Default Runtime Settings. I don't think we need to go adding that anywhere else for the time being.

How about providing a Docker image or something like that with the correct libs preinstalled? Would that be feasible?

IMO a Docker image while nice, should be something internally waited on until after a stable tag. Right now we should focus on the issues with getting it running directly on machines. Improve this experience. And then once we are stable, we can assess how to best provide a docker image for people to use.

currently puppeteer only runs with bleeding edge Chromium. Running against stable won't work at the moment.

@JoelEinbinder Do you plan to switch to stable builds once Chrome 62 lands?

Ah yea, that's it. Your box host is messing you up. It has a very old Kernel. Debian 9 ships with 4.9.0-3 and you're running 3.14.0. So the security features of the kernel are extremely different. So, you may be in a case where you need to fallback to using the older file-based sandbox to have some level of security.

On the latest kernel:

febian:~/p uname -a
Linux febian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 GNU/Linux

febian:~/p node --version
v8.1.1

febian:~/p lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 9.1 (stretch)
Release:        9.1
Codename:       stretch

Still get this warning:

febian:~/p /home/fortes/p/node_modules/puppeteer/.local-chromium/linux-494755/chrome-linux/chrome --no-sandbox --disable-setuid-sandbox

(chrome:23907): Gtk-WARNING **: cannot open display:
[0817/080600.484767:ERROR:nacl_helper_linux.cc(310)] NaCl helper process running without a sandbox!
Most likely you need to configure your SUID sandbox correctly

@Garbee I ran your bash script and got the following:

febian:~/p ./test.sh
You have user namespacing in the kernel. You should be good to go.

FYI, I ran this script: https://raw.githubusercontent.com/Garbee/puppeteer/cd00f7d936c942f8f378a332401024e501b186ce/utils/linux/debian-check.sh -- there are no missing dependencies.

@zackify It is You just have to expand the list of packages out since we don't always want them cluttering up the doc page.

I have also an issue with Ubuntu

(node:10215) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Failed to launch chrome!

Now when I run it manually:

/srv/app/puppeteer/linux-515411/chrome-linux$ ./chrome --no-sandbox --disable-setuid-sandbox
avalon@dev:/srv/app/puppeteer/linux-515411/chrome-linux$ [0227/104848.849621:ERROR:nacl_helper_linux.cc(310)] NaCl helper process running without a sandbox!
Most likely you need to configure your SUID sandbox correctly

Now when I run it just 'as is' there is no output in the terminal:

/srv/app/puppeteer/linux-515411/chrome-linux$ ./chrome 
< no output >

Im using chromium with puppeteer and PKG ( https://github.com/zeit/pkg ) to pack all the modules and node into a single binary. Using latest versions as of now.

Initialization code in my nodejs application is :

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

System version:

Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.3 LTS
Release:	16.04
Codename:	xenial

Cannot get the headless to run, it seems that the chromium is not starting at all, when adding the no sandbox flags it throws the errors above.

I tried to install all the required apt-get packages like listed in the several issues. To no resolve, most of them where already installed

I got this while setting up basic CI support on my code sample repo: https://github.com/kaycebasques/puppeteer-by-example/tree/16c7f2bd0d2a79d062a6d8e3d022e75c47897733

Setting os: osx in my .travis.yml seemed to fix it.

Hello there,

I'm still struggling in trying to make things work on Ubuntu 16.04 Server. I have installed all @coldner 's dependencies and here's the result:

Running as root:

google-chrome --headless --dump-dom http://www.perdu.com/

[0313/102503.396335:ERROR:zygote_host_impl_linux.cc(90)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.

google-chrome --headless --dump-dom --no-sandbox http://www.perdu.com/

[0313/102635.889632:ERROR:gpu_process_transport_factory.cc(1019)] Lost UI shared context.
<html><head><title>Vous Etes Perdu ?</title></head><body><h1>Perdu sur l'Internet ?</h1><h2>Pas de panique, on va vous aider</h2><strong><pre> * <----- vous êtes ici</pre></strong>
</body></html>

Running as non-root:

google-chrome --headless --dump-dom http://www.perdu.com/

[0313/102832.114783:ERROR:gpu_process_transport_factory.cc(1019)] Lost UI shared context.
<html><head></head><body></body></html>

google-chrome --headless --dump-dom --no-sandbox http://www.perdu.com/

[0313/102914.693612:ERROR:gpu_process_transport_factory.cc(1019)] Lost UI shared context.
<html><head></head><body></body></html>

As you can see, it will only work as root, with the --no-sandbox flag. I have also tried with chromium-browser, same result.

Any ideas?

Thank you,
Ben

If you're using lighthouse to run headless chrome, add --no-sandbox in --chrome-flags parameter may fix your error, e.g.

lighthouse ... --chrome-flags='--headless --no-sandbox' ...

Hi guys,

I have this error when using puppeteer.

:Cannot start Chrome
node_modules/puppeteer/.local-chromium/linux-549031/chrome-linux/chrome: error while loading shared libraries: libatk-bridge-2.0.so.0: cannot open shared object file: No such file or directory

Any ideas?
Thanks

Here's a neat alternative to copy-pasting the dependency list:

wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb

apt-get install $( \
  dpkg -I google-chrome-stable_current_amd64.deb | \
  awk '/^ Depends: / { gsub(/Depends:|,|\([^\)]*\)/, ""); print }' \
)

Probably doesn't cover all edge cases, but at least removes the hardcoding. Tested on node:10 image.

Just in case, Chromium's dependencies don't cut it, unfortunately, so can't get by with apt-cache.

i did this as a workaround
ln -s /mnt/c/Program\ Files\ \(x86\)/Google/Chrome/Application/chrome.exe node_modules/puppeteer/.local-chromium/linux-515411/chrome-linux/chrome to get it working on windows linux subsystem (wsl)

If it helps, I followed the advice found in the URL given in the error message (https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md) and changed the file "chrome_sandbox" so that it was owned by root and had setuid set. Now the sandbox error is gone and chrome launches. To summarize:

chown root:root chrome_sandbox
chmod 4755 chrome_sandbox
setenv CHROME_DEVEL_SANDBOX <path>/node_modules/puppeteer/.local-chromium/linux-555668/chrome-linux/chrome_sandbox
# Or use export CHROME_DEVEL_SANDBOX=... if bash

I am deploying to a Cloud Foundry environment that is running debian. I believe this is a CF linux distro. My app runs fine locally and in the CF env but not when I hit an end point that uses Puppeteer. I am pretty sure my issue is the missing libs in this issue but I do not have root access to install them all. I would have to use a buildpack.

Is there anywhere these missing packages are bundled up in a way that I could use to install them into my environment?

@mrbar42 for president!!

If docker is an option (and I'd highly recommend it), I maintain a repo here that adds a lot of features over "just running Chrome" located: here.

@joelgriffith I actually did see that earlier. Thanks though. I actually ran it earlier today and was thinking of trying to use it. I am currently using a Nuxt.js application and I am not really sure how I would convert your repo into my application. I tried copying the Docker file only and ran that in my project but it would not load the home screen.

If you could tell me what it would take to put my project into your repo, I would be grateful to use it.

This is my current situation,

https://stackoverflow.com/questions/50662388/running-headless-chrome-puppeteer-with-no-sandbox

I have the application running in Docker. But, when I try and Docker run with the suggested Docker config I found on line, it throws a few different errors depending on if I run as root or not.

https://github.com/GoogleChrome/puppeteer/blob/master/docs/troubleshooting.md

Error message:
Screenshot failed Error: Failed to launch chrome!
puppeteer/.local-chromium/linux-
/chrome-linux/chrome: error while loading shared libraries: libX11 : cannot open shared object file: No such file or directory

Solution:
To get Chromium screenshots working on Ubuntu 16.04 I had to install the missing libx11 package plus several others which I determined by trail and error. Ultimately installed all these:
(command line: sudo apt install <name>)

• libx11-xcb1
• libx11composite1
• libx11cursor1
• libx11damage1
• libcups2
• libxss1
• libxrandr2
• libpangocairo-1.0-0
• libatk1.0-0
• libatk-bridge2.0-0
• libgtk-3-0

No need for "trial and error" here, the required dependencies were listed a while back in this thread and are in the troubleshooting guide.

@wuno were you able to fix the issue in cloud foundry environment. I am also facing the same issue. I tried --no-sandbox --disable-setuid-sandbox and no luck.

@dkommineni Yes, I have the issue resolved.

Basically you are missing dependencies when you are using CF. Then you will face a second issue once you install the dependencies. That issue is that Puppeteer needs to be ran with options passed to it.

There is a solution you could use if you have control over the CF environment you are deploying to. I was deploying to a large company and did not have control.

If you have control, you could install the missing dependencies into your CF environment with this,

https://github.com/cloudfoundry/apt-buildpack

If you are like me and do not have control, you can take 3 steps to solve this issue.

1. Put the project in a Docker image.

2. Update the code to pass options to Puppeteer

3. Deploy the Docker image to CF

You will find 100 examples of Dockerfiles on line and none of them worked for me. The way I finally got the Dockerfile right was using this,

FROM node:8
ENV HOST 0.0.0.0
EXPOSE 8080
RUN apt-get update

# for https
RUN apt-get install -yyq ca-certificates
# install libraries
RUN apt-get install -yyq libappindicator1 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 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
# tools
RUN apt-get install -yyq gconf-service lsb-release wget xdg-utils
# and fonts
RUN apt-get install -yyq fonts-liberation

RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
COPY . /usr/src/app
RUN mkdir -p /usr/src/app/views

# install the necessary packages
RUN npm install

CMD npm run start

You will need to make sure you update the Dockerfile to have the correct values for port, host and start command. That is up to you and your deployment.

The second thing I had to do was change puppeteer to launch like this,

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

Originally I was launching it like this which will not work on Debian using the Dockerfile mentioned above,

const browser = await puppeteer.launch();

At that point I was able to create the Docker Image and test that Puppeteer was working on my localhost inside of the Docker Image. Once I could see that it was working, I deployed the Docker Image to CF and it worked like a charm on my first try.

This took me 3 or 4 days to figure out AFTER I had failed for a week to get it to work in CF without Docker. I truly hope this helps a ton of people.

Thanks @wuno , I ended up using cloud foundry multi buildpack (https://github.com/cloudfoundry/multi-buildpack), as my organization API is not allowing to use main and supplement build pack (https://github.com/cloudfoundry/apt-buildpack) with cf push. With this multi build pack, we can mention all required buildpacks in a file. One drawback is I have to use buildpacks with URL based and not local buildpacks with this approach.

@dkommineni I also like to use multi-buildpack. But, I do not see how that solves your problem of having missing dependencies when you try to run the application. That is the reason I had to use Docker but suggested the alternative of using apt-buildpack.

apt-buildpack allows you to add a bunch of dependencies that need to be installed with apt-get. If you were able to find a way around that, than that is great. But, if you are still having problems I assume it is for the reason mentioned above.

If you do have a working build file for CF not using Docker but can run Puppeteer, I would be grateful to see it.

@wuno my apology for mis communication. I still use apt-buildpack, as one of the buildpacks configured in (https://github.com/cloudfoundry/multi-buildpack)