Error: Failed to launch the browser process!

[ldesousa]

Describe the bug mmdc fails with the error message: "Error: Failed to launch the browser process!"

To Reproduce

$ mmdc -i PROV.mm -o PROV.png

Error: Failed to launch the browser process!
[0816/165930.731221:FATAL:zygote_host_impl_linux.cc(117)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/main/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 0x58e9b2b224e2 base::debug::CollectStackTrace()
#1 0x58e9b2a93ab3 base::debug::StackTrace::StackTrace()
#2 0x58e9b2a90cf7 logging::LogMessage::~LogMessage()
#3 0x58e9b05a80a2 content::ZygoteHostImpl::Init()
#4 0x58e9b25dc8af content::ContentMainRunnerImpl::Initialize()
#5 0x58e9b25d9f6b content::RunContentProcess()
#6 0x58e9b25da4fe content::ContentMain()
#7 0x58e9b263c3c6 headless::(anonymous namespace)::RunContentMain()
#8 0x58e9b263c068 headless::HeadlessShellMain()
#9 0x58e9aeb251e3 ChromeMain
#10 0x714505e2a1ca (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9)
#11 0x714505e2a28b __libc_start_main
#12 0x58e9aeb2502a _start



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

    at onClose (file:///usr/local/lib/node_modules/@mermaid-js/mermaid-cli/node_modules/puppeteer-core/lib/esm/puppeteer/node/BrowserRunner.js:269:20)
    at Interface.<anonymous> (file:///usr/local/lib/node_modules/@mermaid-js/mermaid-cli/node_modules/puppeteer-core/lib/esm/puppeteer/node/BrowserRunner.js:257:24)
    at Interface.emit (node:events:529:35)
    at Interface.close (node:internal/readline/interface:534:10)
    at Socket.onend (node:internal/readline/interface:260:10)
    at Socket.emit (node:events:529:35)
    at endReadableNT (node:internal/streams/readable:1400:12)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21)

Expected behavior Expected mmdc to generate an image and exit without error messages.

Desktop (please complete the following information):

• OS: Ubuntu 24.04
• Browser Brave, Firefox
• Version Version 1.68.141 Chromium: 127.0.6533.120 (Official Build) (64-bit), 129.0 (64-bit)

[aloisklink]

Are you running Ubuntu 24.04 and mmdc in a docker/podman container?

If so, you'd either need to add the --cap-add=SYS_ADMIN (not recommended!) to your container, or run puppeteer with the --no-sandbox arg (which is dangerous, but should be mostly safe, as long as there is nothing else in the container that you care about).

You can do this by creating a puppeteerConfig.json file with the contents:

{
  "args": ["--no-sandbox"]
}

Then running mmdc with mmdc --puppeteerConfigFile path/to/my/puppeteerConfig.json -i PROV.mm -o PROV.png.

As an example, you can see how the official minlag/mermaid-cli docker image does this with:

• Dockerfile
• puppeteer-config.json

There's also some alternative steps which are recommended by the Puppeteer team at https://pptr.dev/troubleshooting#setting-up-chrome-linux-sandbox, but I haven't tested them yet.

[ldesousa]

Are you running Ubuntu 24.04 and mmdc in a docker/podman container?

No. This issue does not concern Docker.

[aloisklink]

I recently updated to Ubuntu 24.04 and encountered the same issue!

It looks like Ubuntu 24.04 contains some AppArmor 4 rules that block Puppeteer's sandbox from working properly: https://github.com/puppeteer/puppeteer/issues/12818#issuecomment-2250443567

The easiest thing to do is probably just to prepend all calls to @mermaid-js/mermaid-cli with aa-exec --profile=chrome (see aa-exec).

E.g., if you normally use npx @mermaid-js/mermaid-cli, instead use aa-exec --profile=chrome npx @mermaid-js/mermaid-cli.

Other options would be to:

• Create a new profile in /etc/apparmor.d for Puppeteer.
• Create a puppeteer-config.json file that contains {"executablePath": "/path/to/a/browser/that/already/has/an/entry/in/apparmor.d/e.g./chrome/or/firefox"} and passing it to mermaid-cli
• Or, you could always disable the sandbox completely using the instructions in https://github.com/mermaid-js/mermaid-cli/blob/340561040b6b0621a486e3fc96723139e5718268/docs/linux-sandbox-issue.md, but that has some security implications, so you shouldn't do this unless you trust all the mermaid diagrams you're running mermaid-cli on.

[eeproto]

Had the same issue after upgrading to 24.04. I did not want to poke any holes into system security globally, so opted to patch just the puppeteer call from mermaid-cli.

Go into node_modules/@mermaid-js/mermaid-cli/src/index.js and look in async function cli () for the statement setting the puppeteerConfig variable. Modify it such that it includes the --no-sandbox option, like this:

  let puppeteerConfig = ({
    headless: 1,
    args: ['--no-sandbox']
  })

That worked for me. I am using mermaid through the pandoc mermaid-filter module in version 1.4.7.

If you are on the same version, and run a unix/linux flavor, you can use this patch to achieve the same result:

176c176,177
<     headless: 1
---
>     headless: 1,
>     args: ['--no-sandbox']

Put this into a file sandbox_workaround.patch this next to your index.js file and run

patch index.js sandbox_workaround.patch

[sillydan1]

I also ran into this problem today and adopted the same solution as @eeproto and I want to throw in my two cents.

Perhaps a solution here would be to have a default value for the --puppeteerConfigFile argument to be set as "$XDG_CONFIG_HOME/puppeteer/config.json" or "$XDG_CONFIG_HOME/mermaid/puppeteer.json" or similar?

That way, if the file exists, it can be loaded and we don't have to patch index.js manually. If the file does not exist, we just use the default values as is being done today.

[aloisklink]

Perhaps a solution here would be to have a default value for the --puppeteerConfigFile argument to be set as "$XDG_CONFIG_HOME/puppeteer/config.json" or "$XDG_CONFIG_HOME/mermaid/puppeteer.json" or similar?

I'm up for it, but I don't think we should enable or recommend using --no-sandbox by default. If you're running it on untrusted Mermaid diagrams and there's a browser bug, it's potentially dangerous, see https://pptr.dev/troubleshooting/#issues-with-apparmor-on-ubuntu. But it could still be a good idea in case you want to specify your own version of Chromium/Firefox to use (which are probably allowed by Ubuntu's default AppArmor rules)!

Maybe "$XDG_CONFIG_HOME/mermaid-cli/puppeteer.json" in XDG devices? We should probably also add equivalents for Windows/MacOS/BSD/etc.

@MindaugasLaganeckas, what are your thoughts?

It also seems like Puppeteer also has built-in support for config files, see https://pptr.dev/guides/configuration#configuration-files, but they don't look in the XDG_CONFIG_HOME folder. I wonder if it makes more sense to add it there, since @mermaid-js/mermaid-cli only has ~120k monthly downloads, but puppeteer has ~3 million monthly downloads.

[sillydan1]

It also seems like Puppeteer also has built-in support for config files, see https://pptr.dev/guides/configuration#configuration-files, but they don't look in the XDG_CONFIG_HOME folder. I wonder if it makes more sense to add it there, since @mermaid-js/mermaid-cli only has ~120k monthly downloads, but puppeteer has ~3 million monthly downloads.

It seems that the native puppeteer configuration doesn't enable the possibility to set --no-sandbox through there. There's also an open issue over there that talks about this exact problem. That issue is almost 5 years old now. I don't think puppeteer will implement this - at least not anytime soon.

[jsoref]

Is it unreasonable for mermaid-cli to proactively determine that puppeteer won't work and trigger things with aa-exec / chrome?

I'm running this command (on a github ubuntu-24 runner):

npx -p @mermaid-js/mermaid-cli mmdc --input "$file" --output "$file"

... because somewhere I saw some cargo cult stuff which implied that it'd be a good way to convert markdown with embedded mermaid diagrams into things with svg or something...

It seems like a bit of a reach to expect each user to have to figure out how to beg thirty layers down in order to have a command-line tool "just work". Note that the error message that users see points to puppeteer, not mermaid, which is confusing because users didn't install puppeteer and didn't try to run puppeteer, they installed and tried to run mermaid-cli.

At the very least, the version of Ubuntu is easily discoverable, so it should be pretty easy to determine that chromium or whatever puppeteer favors won't work and select something that would/should.

If necessary, such a change could be a major version bump to warn people that mermaid-cli will now try to run a different browser in order to do something (with my end user hat on, i have no idea why mermaid-cli is trying to ask a puppeteer in order to run a web browser).