I have been trying to get the headless chrome / google chrome to run on EC2 instance with a GPU (g4dn.xlarge). The purpose of it would be to stream video game application.
I followed this article to setup the instance with the necessary GPU driver and packages. https://dev.to/mirzabilal/how-to-enable-hardware-acceleration-on-chrome-chromium-puppeteer-on-aws-in-headless-mode-50hd
This is a step in the article where the chrome://gpu page is opened on the headless chrome and the screenshot of it gets output as output.pdf.
google-chrome-stable --headless --use-gl=angle \
--use-angle=gl-egl --use-cmd-decoder=passthrough \
--print-to-pdf=output.pdf 'chrome://gpu'
The problem I'm facing is that instead of opening chrome://gpu it opens up chrome://new-tab-page I have attached snip of the pdf for reference.
I did encounter a few errors when I run the above command. Here's the log
[4175:4269:0911/053816.001929:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[4175:4269:0911/053816.002261:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[4175:4269:0911/053816.002550:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
30025 bytes written to file output.pdf
[4214:4214:0911/053819.617095:ERROR:shared_image_manager.cc(224)] SharedImageManager::ProduceSkia: Trying to Produce a Skia representation from a non-existent mailbox.
[4214:4214:0911/053819.618405:ERROR:shared_image_manager.cc(224)] SharedImageManager::ProduceSkia: Trying to Produce a Skia representation from a non-existent mailbox.
I'm quite clueless on what to do next. I'd really appreciate the help in figuring it out
I tried running the chromium version as well. It has the same issue.
I ensured that the driver is installed and running using the nvidia-smi command.
The Ubuntu version is 24.04, the Nvidia driver version is 560.35.03. Google Chrome 128.0.6613.119
I used Claude 3.5 Sonnet quite a lot to figure out a solution for this, but no luck there either
Currently from versions 122 upwards Chrome/Chromium cores are evolving away from using one executable model into two.
One designed for Browsing with Puppeteer and one for simplified headless tasks.
The first move was to add a --headless=new and --headless=old switch, this worked well upto version 127.
Then default the new behaviour to the be the default overriding the --headless behaviours, this worked well upto version 127.
The aim is to remove the headless switch for basic tasks such as screenshot or PDF printing.
So going forward there is a core executable specifically called chrome-headless-shell that works in a different graphics headless context.
It would in simplest cases be used as save input to an absolute addressed file,
Chrome-headless-shell --print-to-pdf=drive:/folder/output.pdf URL://remote/local
For now the current shell versions are listed in a way they can be auto downloaded and I have shown a windows solution at Headless Chrome to print pdf
Shown here as overlapping questions tend to be deleted.
Helper script (download.cmd). Replace the 2 win32 with win64 or adapt script for mac/linux OS variants if you wish.
set "download=chrome-headless-shell-win32.zip"
set "variant=win32/%download%"
curl -o LATEST_RELEASE_STABLE.txt https://googlechromelabs.github.io/chrome-for-testing/LATEST_RELEASE_STABLE
set /p version=<LATEST_RELEASE_STABLE.txt
curl -O https://storage.googleapis.com/chrome-for-testing-public/%version%/%variant%
tar -xf %download%
The URL in this case is less conventional as not file:/// or https:// but an internal chrome://invocation (GPU report) thus may not work with simplified headless executable.
However the OP Qile has found the switch for accessing internal chrome addresses is
--allow-chrome-scheme-url 'chrome://gpu'
I tested with headless shell where it did not work HOWEVER Qile found it did work with google-chrome-stable! So this may be the best future usage?
google-chrome-stable --headless --use-gl=angle --use-angle=gl-egl --use-cmd-decoder=passthrough --print-to-pdf=output.pdf --allow-chrome-scheme-url 'chrome://gpu'
As an interim measure, until fully test out migration, (there are 3 executable streams for now!). You can rollback a working system to legacy behaviour, by switch --headless to old.
google-chrome-stable --headless=old --use-gl=angle --use-angle=gl-egl --use-cmd-decoder=passthrough --print-to-pdf=path/output.pdf 'chrome://gpu'
I suggest that you double-check with the chromium teams what system is to be used in this case for the future as old headless is likely to be removed soon.