[Bug]: Headless=new fails to start Chrome without sandbox

[nicknotfun]

Bug expectation

I'm running Chrome without sandbox in a Kubernetes environment, after much bisection I've narrowed the issue to this:

./chrome --no-sandbox --disable-settuid-sandbox --remote-debugging-port=9229 --headless

Works.

./chrome --no-sandbox --disable-settuid-sandbox --remote-debugging-port=9229 --headless=new

Fails with

[0612/155842.955117:ERROR:nacl_helper_linux.cc(355)] NaCl helper process running without a sandbox!
Most likely you need to configure your SUID sandbox correctly

Bug behavior

• Flaky
• PDF

Minimal, reproducible example

import puppeteer from 'puppeteer'; // TS/ESM are all supported.

void puppeteer.launch({ headless: "new", args: [    "--no-sandbox",
    "--disable-setuid-sandbox" ] });

Error string

no error

Puppeteer configuration

No response

Puppeteer version

20.6.0

Node version

20.0.0

Package manager

yarn

Package manager version

1.22.19

Operating system

Linux

[github-actions]

This issue was not reproducible. Please check that your example runs locally and the following:

• Ensure the script does not rely on dependencies outside of puppeteer and puppeteer-core.
• Ensure the error string is just the error message.

  • Bad:

    Error: something went wrong
      at Object.<anonymous> (/Users/username/repository/script.js:2:1)
      at Module._compile (node:internal/modules/cjs/loader:1159:14)
      at Module._extensions..js (node:internal/modules/cjs/loader:1213:10)
      at Module.load (node:internal/modules/cjs/loader:1037:32)
      at Module._load (node:internal/modules/cjs/loader:878:12)
      at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
      at node:internal/main/run_main_module:23:47

  • Good: Error: something went wrong.

• Ensure your configuration file (if applicable) is valid.
• If the issue is flaky (does not reproduce all the time), make sure 'Flaky' is checked.
• If the issue is not expected to error, make sure to write 'no error'.

Once the above checks are satisfied, please edit your issue with the changes and we will
try to reproduce the bug again.

---

Analyzer run

[OrKoN]

Does it work with a sandbox? Note that we don't recommend running without the sandbox and, in general, there are no guarantees about stability of command line flags in Chromium. In any case, we need to report it to crbug.com but it will likely be classified as working as expected.

[nicknotfun]

Updated as I think this isn't a Puppeteer bug but rather Chrome not respecting no-SUID sandbox for the child process. But it should affect Puppeteer's adoption of that mode as the default.

[nicknotfun]

It does appear to be okay with the sandbox configured appropriately. And I am aware of the recommendation- just also aware of the current warning about headless mode=new being the new default.

It is annoyingly difficult to run a sandbox mode in Kubernetes so why we avoid it for now (it's rendering our own content server-side so we have no concerns)

[OrKoN]

Could you please report it to crbug.com (the Internals>Headless component) and post the issue here?

[OrKoN]

Filed https://crbug.com/1454349

[Schaka]

I just spent the better part of a day trying to solve this very issue before ending up here.
Similarly to OP, getting sandbox mode to run reliably in kubernetes is very hard and at least in Chrome 115 stable, it still does not work to this day.

@nicknotfun were you able to figure this out? Maybe switch to a Chromium beta release or something? Or did you end up running with the sandbox?

[OrKoN]

Unable to repro with M117.

[Schaka]

Chrome: 117.0.5938.88-1
Puppeteer: 21.3.1
Headless: 'new'

Startup params:

'--no-sandbox',
'--disable-setuid-sandbox',
'--homepage=about:blank',
'--no-first-run',
'--disable-dev-shm-usage',
'--disable-gpu',
'--disable-accelerated-2d-canvas',
'--disable-canvas-aa',
'--disable-2d-canvas-clip-aa',
'--disable-gl-drawing-for-tests',
'--disable-extensions',
'--disable-sync',
'--metrics-recording-only',
'--disable-default-apps',
'--no-crash-upload',
'--ignore-certificate-errors',
'--use-gl=swiftshader',
'--disable-software-rasterizer',
'--disable-breakpad',
'--disable-crashpad',
'--font-render-hinting=none',
'--no-default-browser-check'

Starting docker image locally (MacOS Ventura 13.1), no problems. Browsers start up.
Inside Kubernetes cluster:

orker start failed: Error: Failed to launch the browser process!
chrome_crashpad_handler: --database is required
Try 'chrome_crashpad_handler --help' for more information.
[165:165:0921/100345.161235:ERROR:socket.cc(120)] recvmsg: Connection reset by peer (104)


TROUBLESHOOTING: https://pptr.dev/troubleshooting

    at Interface.onClose (/home/crawler/service/dist/node_modules/@puppeteer/browsers/lib/cjs/launch.js:277:24)
    at Interface.emit (node:events:526:35)
    at Interface.emit (node:domain:489:12)
    at Interface.close (node:internal/readline/interface:533:10)
    at Socket.onend (node:internal/readline/interface:259:10)
    at Socket.emit (node:events:526:35)
    at Socket.emit (node:domain:489:12)
    at endReadableNT (node:internal/streams/readable:1359:12)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21)

Right now it's not mission critical, because we can use Chrome 115 and an older Puppeteer version with headless: true. But I'd be thankful for any pointers.

[OrKoN]

@Schaka could you file an issue for the headless component at crbug.com including a repro for your environment? thanks.

[Schaka]

For anyone else stumbling across this: Chrome will NOT run in Docker using 117 and headless=new when using a readonly root-fs. You need to write to the rootfs or at least map the user folder of the user you're using to start Chrome. I don't know which parts of it exactly are the issue, but it looks like Chrome is creating a bunch of files in the home directory and some others.