Get chromium remote dev tools running on Balena Dash

Hello, I am trying to debug my slow chromium on a Fin, I am trying to follow this tutorial

I am not sure why it is not working but I have added --remote-debugging-port=9222 --incognito onto the chromium-browser command as well as added the

      - 8080:8080
      - 80:9222

When I open the device public url I get the following

We encountered an error when reaching this device:

UUID 3126d7f8b1d20839faa1dd8476696b41

tunneling socket could not be established: 500

One possible reason is because nothing is listening on port 80 on the device

Why can I access it?

Do you have the logs from the device ?
Are you sure chromium is listening on port 9222 in the container ?
You can check with netstat -ltn in the container.
If you’re on the same network as the device, you can try to directly open http://<device-ip> in a browser.

Thanks @zvin,

I get the following after setting

      - 8080:8080
      - 9222:9222

the ports

root@3126d7f:~# netstat -ltn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0  *               LISTEN
tcp        0      0*               LISTEN
tcp        0      0 :::48484                :::*                    LISTEN
tcp        0      0 :::9222                 :::*                    LISTEN
tcp        0      0 :::2375                 :::*                    LISTEN
tcp        0      0 :::22222                :::*                    LISTEN
tcp        0      0 :::8080                 :::*                    LISTEN

However if I scan for my device, and get the IP:, and try visit it, or, I just get

This site can’t be reached

Ive also tried --headless --no-sandbox too

and EXPOSE 9222

Any ideas why this is not working?

Can you connect toper 9222 from within the device? If that works, then we know there is something wrong with how that port is getting exposed, and dig further on that. Otherwise, it’d indicate a problem in how Chrome is being ran

Yes I can,
In the host OS, I can ping it

root@3126d7f:~# ping
PING ( 56 data bytes
64 bytes from seq=0 ttl=64 time=0.321 ms
64 bytes from seq=1 ttl=64 time=0.247 ms
64 bytes from seq=2 ttl=64 time=0.258 ms
64 bytes from seq=3 ttl=64 time=0.274 ms

Hey Patrick,

Is there a chance you can share the app code with us, so we can inspect it and see if there is something going on? I’m particularly interested in the container than runs Chrome, and the docker-compose.yml definition

Hello, you can’t ping a port.
To check if it works you’d need to run telnet 9222.
I guess it works as it listens on :::9222. (I don’t know why it doesn’t listen on though).
You should see in chromium logs something like

DevTools listening on ws://

Anyway, it turns out --remote-debugging-port only listens on the loopback interface so it won’t be reachable from another computer.
You’ll need to run an http proxy on redirecting to, tinyproxy or anything similar.
For reference:

Even simpler than tinyproxy: simpleproxy -L <device ip address>:9222 -R

And even simpler: listen on another port:
simpleproxy -L 9223 -R
In your compose file use 80:9223


I am getting this reponse from telnet

telnet 9222
Connection closed by foreign host

When I run it in the host os or in my service

Here is my docker compose

version: "2"
    restart: always
    build: ./kiosk
      io.balena.features.kernel-modules: "1"
      io.balena.features.firmware: "1"
      io.balena.features.dbus: "1"
      io.balena.features.supervisor-api: "1"
      io.balena.features.balena-api: "1"
    privileged: true
      - DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
      - 8080:8080
      - 80:9223
      - "settings:/usr/src/app/settings"

After making your changes

And my docker.fincm3

# build tohora from source
FROM balenalib/raspberrypi3-golang as builder

RUN go get -d -v

WORKDIR /go/src/

RUN go build 

# use smaller image
FROM balenalib/rpi-raspbian

RUN install_packages wget \
    xserver-xorg-video-fbdev \
    xserver-xorg xinit \
    xterm x11-xserver-utils \
    xterm \
    dbus-x11 \
    dbus \
    xserver-xorg-input-evdev \
    xserver-xorg-legacy \
    mesa-vdpau-drivers \
    chromium-browser \
    rpi-chromium-mods \ 
    libgles2-mesa \
    lsb-release \

# Setting working directory
WORKDIR /usr/src/app

ENV FLAGS $KIOSK --remote-debugging-port=9222 --headless --no-sandbox --incognito --disable-dev-shm-usage --ignore-gpu-blacklist --enable-gpu-rasterization --force-gpu-rasterization --autoplay-policy=no-user-gesture-required --user-data-dir=/usr/src/app/settings --enable-features=WebRTC-H264WithOpenH264FFmpeg --window-position=0,0

# Add chromium user
RUN useradd chromium -m -s /bin/bash -G root && \
    groupadd -r -f chromium && id -u chromium \
    && chown -R chromium:chromium /home/chromium  

# udev rule to set specific permissions 
RUN echo 'SUBSYSTEM=="vchiq",GROUP="video",MODE="0660"' > /etc/udev/rules.d/10-vchiq-permissions.rules
RUN usermod -a -G audio,video,tty chromium

COPY public_html /home/chromium/public_html

COPY --from=builder /go/src/ /home/chromium/tohora

COPY /home/chromium/

CMD ["bash", ""]

What happens if you run it from the container running chromium ?

Sorry, In my service, means, in the chromium container

Hi Patrick,

Last night I tried to get my Fin into a representative state to test this for you, using your site (and some test login details that Daniel gave me) and a TV with the same resolution you are using. Initially I could see that there was lag, especially when opening the site initially. I used the Chromium menu’s to open task manager, and saw that the GPU process was maxing out the CPU. I believe that’s because the options --enable-gpu-rasterization --force-gpu-rasterization are causing the screen to render on the GPU, but hardware acceleration isn’t enabled (or enabled but not working) for the CM3. This results in a high CPU load. To test this theory I disabled those flags and ran the site again, and found it to be much more performant. There was still some lag, but this is quite a large screen to be driven by a Cortex-A53 CPU with only 1Gb of memory - and I found the site to be very usable.

For now I think the next thing to try (before we continue trying to get Chromium DevTools working) is to use the site with the GPU disabled. You can do this by setting the following in an environment variable on the KIOSK service, set FLAGS to --disable-dev-shm-usage --user-data-dir=/usr/src/app/settings --window-position=0,0 which effectively removes the flags trying to enable the GPU use.

For context: the GPU flags are there to try and make running YouTube videos and WebGL content performant. For displaying web content on balenaDash which does not have video or WebGL, they are not needed and seem to cause higher CPU load.

Please let me know how this testing goes, and I’ll leave my Fin set up for your application in case I can help further.

Thanks a lot @phil-d-wilson ,

There is a noticeable improvement when I do that. Does that mean that you can set Define device GPU memory in megabytes to 0?


Good question…let me try and get back to you.


Hi Patrick,

You can set the value to zero, but I believe the minimum is actually 16, which the OS will default to. I’ve just run your site again, and it worked fine with this setting. I didn’t notice any improvement, but it makes sense to minimise the amount of memory allocated to the GPU in your case.


Thanks @phil-d-wilson,

Its working a lot better now

You’re very welcome!

I’ll close this support thread (as long as you are happy) but keep looking into the Chrome DevTools in case you do need them, and because it will potentially benefit others. If you have any more questions or issues, you can still reply here and the thread will re-open.