Puppeteer.LaunchAsync is hanging in Ubuntu

[kcfinished]

Description:
I just pulled the latest master source code and go to an example get-all-links

then I typed dotnet build and dotnet run

after that it's hanging in the line of Puppeteer.LaunchAsync

I also saw this issue #696

but it was last year ago, so any updates to run it on Linux

Out put:

Downloading chromium
Navigating to google.com

Expected behavior:
Puppeteer is launched and get all the links of google.com

Actual behavior:
Puppeteer hangs.

Versions
Puppeteer version: 1.9.0
.NET version: .NET core 2.1
Ubuntu version: Ubuntu 16.04.6 LTS

Thank you for your help.

[kblok]

@kcfinished you might have got a .local-chromium folder into your bin file. Inside you should also have got a chromium folder. Could you check if you are able to run the chromium app located on that folder?

[A7250AG]

@kblok this is from Debian Buster, but may help. Adding the --no-sandbox argument does indeed allow PuppeteerSharp to work for me with netcoreapp2.2 in debian 10 in headless mode to take screenshots.

`
[32011:32011:0817/234616.202089:FATAL:zygote_host_impl_linux.cc(116)] 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 0x55983958ca99 base::debug::CollectStackTrace()
#1 0x5598394ed3e3 base::debug::StackTrace::StackTrace()
#2 0x559839501943 logging::LogMessage::~LogMessage()
#3 0x55983ac3266e service_manager::ZygoteHostImpl::Init()
#4 0x55983911408c content::ContentMainRunnerImpl::Initialize()
#5 0x55983915fd1c service_manager::Main()
#6 0x559839112661 content::ContentMain()
#7 0x559836f7e1bf ChromeMain
#8 0x7facc6e7d09b __libc_start_main
#9 0x559836f7e02a _start

Received signal 6
#0 0x55983958ca99 base::debug::CollectStackTrace()
#1 0x5598394ed3e3 base::debug::StackTrace::StackTrace()
#2 0x55983958c621 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#3 0x7facc931b730
#4 0x7facc6e907bb gsignal
#5 0x7facc6e7b535 abort
#6 0x55983958b465 base::debug::BreakDebugger()
#7 0x559839501c27 logging::LogMessage::~LogMessage()
#8 0x55983ac3266e service_manager::ZygoteHostImpl::Init()
#9 0x55983911408c content::ContentMainRunnerImpl::Initialize()
#10 0x55983915fd1c service_manager::Main()
#11 0x559839112661 content::ContentMain()
#12 0x559836f7e1bf ChromeMain
#13 0x7facc6e7d09b __libc_start_main
#14 0x559836f7e02a _start
r8: 0000000000000000 r9: 00007ffc0c819ba0 r10: 0000000000000008 r11: 0000000000000246
r12: 00007ffc0c81ae68 r13: 00007ffc0c819e48 r14: 00007ffc0c81ae70 r15: 00007ffc0c81ae78
di: 0000000000000002 si: 00007ffc0c819ba0 bp: 00007ffc0c819df0 bx: 0000000000000006
dx: 0000000000000000 ax: 0000000000000000 cx: 00007facc6e907bb sp: 00007ffc0c819ba0
ip: 00007facc6e907bb 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.
`

[kblok]

Closed due to inactivity. Feel free to reopen it if needed.

[WhiteBlackGoose]

Had the same problem, here's what I get if I start it myself

But running it with --no-sandbox makes it work.

Here's the fix

launchOptions.Args <- [| "--no-sandbox" |]