docker-headless-vnc-container
docker-headless-vnc-container copied to clipboard
ConSol
Can't open chrome and firefox
Image
Detailed error description i want to run chromium browser but why when i open it nothing happens. chromium doesn't open and i don't get any notification. please tell me how to fix it because i really need chromium.
Additional content
I used docker hub to download console/debian-xfce-vnc:latest
With a somewhat recent change to the script launching Chromium, the ability to insert CHROMIUM_FLAGS from the environment has been blocked. CHROMIUM_FLAGS is simply cleared out at the start of the script.
This used to be a feature, where the launcher would read $HOME/.chromium-browser.init into CHROMIUM_FLAS, and later use the CHROMIUM_FLAGS from the environment. Both situation are covered by the container startup scripts.
/dockerstartup/chrome-init.sh writes the current settings to $HOME/.chromium-browser.init
/dockerstartup/vnc_startup.sh both calls this script and sources the generated output to set the environment.
Now that this no longer works perhaps having /dockerstartup/chrome-init.sh writing a file to /etc/chromium.d/ instead could be a solution.
I'm seeing the same or similar issue. Firefox works but Chromium won't start. From the terminal, the process appears to hang with no output. From ps ax I see both a chromium and chrome_crashpad_handler process, but there's nothing in the 'Crash Reports' folder. Running with strace shows it's hanging on a socket recv. I've tried with and without --no-sandbox (in args or in env), with --privileged on the Docker container, etc. but it behaves the same regardless. This is occurring on both the Debian and Rocky images.
@DeltaWhy I'm seeing the same for Chromium on Rocky 9 XFCE desktop. After changing the configuration on Debian 12 XFCE desktop (i.e., moving the CHROMIUM_FLAGS shenanigans to a file /etc/chromium.d/desktop-flags) Chromium works in that context.
What I do see on Rocky 9 XFCE desktop though is that, when using strace -f, is that it seems to be chrome_crashpad_handler being stuck on a futex, while chromium-browser seems to be receiving on a socket, probably waiting for chrome_crashpad_handler to send something? This behavior isn't impacted however I try to set the command line for chromium-browser. Using the defaults (from chromium-browser.sh), user override with the ~/.chromium-browser.init or a combination of the two, or none at all.
There's only so much I can do, and this is it for now. Once this is resolved I may be able to push a change to fix Chromium on Debian 12 XFCE desktop. Now this change just does not match the needs for Chromium on Rocky 9 XFCE desktop.
I switched to https://github.com/accetto/debian-vnc-xfce-g3 which is working with the latest Chromium. I did not try their Rocky image, but if it's working you might be able to gain some info from there.
i am using image: "docker.io/consol/rocky-xfce-vnc:latest" platform: "linux/arm64"
i have to run chromium from the terminal with --no-sandbox to get it running. It seems to be reacting to the permissions of the home directory without that flag? I mount in a volume as a persistent home dir, and ownership of the directory ends up as root:root with mode 777
