Unable to Open Display (Chrome, Pi)

Occasionally on reboot I’m not able to open the display. It gets stuck on the splash screen. This specifically seems to happen after pushing an update from Balena. Is there a setting I should change to make sure it kills x windows on start?

Any tips to avoid this issue?

20.03.19 12:35:45 (-0400)  frontend  (EE)

20.03.19 12:35:45 (-0400)  frontend  Fatal server error:

20.03.19 12:35:45 (-0400)  frontend  (EE) Server is already active for display 0

20.03.19 12:35:45 (-0400)  frontend     If this server is no longer running, remove /tmp/.X0-lock

20.03.19 12:35:45 (-0400)  frontend     and start again.

20.03.19 12:35:45 (-0400)  frontend  (EE)

20.03.19 12:35:45 (-0400)  frontend  (EE)

20.03.19 12:35:45 (-0400)  frontend  Please consult the The X.Org Foundation support

20.03.19 12:35:45 (-0400)  frontend      at [http://wiki.x.org](http://wiki.x.org/)

20.03.19 12:35:45 (-0400)  frontend   for help.

20.03.19 12:35:45 (-0400)  frontend  (EE)

20.03.19 12:36:00 (-0400)  frontend  xinit: giving up

20.03.19 12:36:00 (-0400)  frontend  xinit: unable to connect to X server: Connection refused

20.03.19 12:36:00 (-0400)  frontend  xinit: server error

Hi,
I was a bit confused since originally you said “on reboot” but later added “seems to happen after pushing an update from Balena”.
Does happen on device reboot, or during container restart (eg after downloading a new release).
Does the issue occur consistently on container restarts? If so, could you try making your container to check whether Xord is already running and connect to it, or kill it and start it again if that’s a better match for you?

Could you share some of the code that you use to spin up Xorg along with any special configuration that you use on your docker-compose?
Please also clarify the exact OS version & device type that this happens.

Hi @thgreasi, thanks for the help.

So I have to run some tests because it doesn’t consistently happen. I have seen it occur in all 3 situations though.

  • After downloading a new release (this seems to happen the most)

  • On container restarts

  • Even on a boot, while plugging the unit in (that happened this morning)

It does start and boot correctly probably > 95% of the time though.

We’re building a tv app. The app has two containers;

  • BACKEND - which is a node/react app communicating via websockets.

  • FRONTEND - chromium browser connects to the exposed port.

We are running on the Raspberry Pi 3+. OS images are;

  • BACKEND: - FROM resin/raspberrypi3-node:8

  • FRONTEND - FROM balenalib/raspberrypi3-debian:stretch

The frontend configuration was actually based on a comment from @ aliasbits in this forum, GUI kiosk on prodution resinOS

As it stands. I have;

entrpoint.sh

#!/bin/bash
umount /dev/shm && mount -t tmpfs shm /dev/shm

env > cron_env_file

# start cron
cron

sleep 25
xinit /home/viewer/launchBrowser.sh -- -nocursor

launchBrowser.sh

#!/bin/bash
#Disable DPMS / Screen blanking
xset -dpms
xset s off
xset s noblank

URL=$URL
default='http://localhost:8888/'


while :        # run forever
do
    echo "Launching Browser"
    echo "Browser is ${URL}"
    DISPLAY=:0 sudo chromium-browser --no-sandbox --window-size=7000,7000 --kiosk --start-fullscreen -a --disable-infobars --no-first-run --disable-web-security --user-data-dir --incognito --allow-file-access-from-files --enable-offline-auto-reload-visible-only --disable-gpu --force-device-scale-factor=0.5 ${URL:-$default} viewer
done

Dockerfile:

FROM balenalib/raspberrypi3-debian:stretch


USER root

RUN apt-get update && apt-get install -y --no-install-recommends \
lsb-release \
nano \
chromium-browser \
omxplayer \
scrot \
cron \
sed \
xorg \
xinit \
xinput \
xserver-xorg \
xserver-xorg-legacy \
xserver-xorg-input-evdev \
xserver-xorg-input-libinput \
x11-xserver-utils && \
apt-get clean && rm -rf /var/lib/apt/lists/*

RUN sed -i "s|allowed_users=console|allowed_users=anybody|" /etc/X11/Xwrapper.config

RUN groupmod -g 19 input # may differ

RUN groupadd viewer && \
echo ‘notsecure\nnotsecure’ | adduser --home /home/viewer --ingroup viewer viewer && \
usermod -aG tty viewer && \
usermod -aG input viewer

COPY entrypoint.sh /home/viewer/entrypoint.sh
COPY launchBrowser.sh /home/viewer/launchBrowser.sh

COPY screenshoter.sh /home/viewer/screenshoter.sh
COPY restartBrowser.sh /home/viewer/restartBrowser.sh
COPY restartAllServices.sh /home/viewer/restartAllServices.sh
COPY cron_env_file /home/viewer/cron_env_file

RUN chmod +x /home/viewer/*
RUN chown viewer:viewer /home/viewer/*

# Add crontab file in the cron directory
ADD crontab /etc/cron.d/hello-cron
# Give execution rights on the cron job
RUN chmod 0644 /etc/cron.d/hello-cron
# Apply cron job
RUN crontab /etc/cron.d/hello-cron

# Allow viewer user to start cron daemon with sudo
RUN echo 'viewer ALL=NOPASSWD: /usr/sbin/cron' >>/etc/sudoers


CMD bash -C "/home/viewer/entrypoint.sh";"bash"

Could it be a power supply issue, it giving not enough power ? I’ve seen the device being stuck in a certain display states when having power supplies that could not keep up with powering both raspberry pi and the display at the same time. Can you access the device via the terminal while this is happening or is the device as a whole unresponsive ?

@cyplo it’s not a power supply issue. I think I’m not configuring it properly.

The device powers up. Both containers are running. Backend is logging, I can ssh into frontend/backend containers. It just get’s stuck on the balena splash screen, as it is unable to open display 0.

Error message

(EE) Server is already active for display 0

@thgreasi using my dockerfile/sh scripts how would I check the xord is running and properly configure it to make sure that I don’t accidently kill it?

here is the docker compose too

version: '2'
volumes:
    resin-data:
services:
  frontend:
    build: ./frontend
    privileged: true
    network_mode: "host"
    depends_on:
      - backend
    volumes:
      - 'resin-data:/data'
    labels:
      io.balena.features.supervisor-api: '1'
  backend:
    build: ./backend
    network_mode: "host"
    ports:
      - "8888:8888"
    volumes:
      - 'resin-data:/data'
    labels:
      io.balena.features.supervisor-api: '1'

Hey @Medistream

there is nothing that strikes me as wrong in the config you posted.
From what I understand, the server will create this lockfile and write into it the PID of the process that is holding this lock.

In your entrypoint.sh, before launching xinit you could try reading /tmp/.X0-lock. If the file is not there, the error shouldn’t occur. If the file is there and contains a PID you could try ps -p to get more info on what process is acquiring the lock and eventually use the PID to kill it.

Let us know how this goes, we might be able to understand the issue better if we understand how the lockfile is being created.

@nazrhom thanks this helped me look in the right place(I think).

I just pushed out an update. stuck at the splash screen and I have this.

03.04.19 22:12:24 (-0400)  frontend  xinit: giving up
03.04.19 22:12:24 (-0400)  frontend  xinit: unable to connect to X server: Connection refused
03.04.19 22:12:24 (-0400)  frontend  xinit: server error

There is a /tmp/.X0-lock.

When I cat it I get 19

But when I run top there is no process with id 19

I get…

Tasks:   5 total,   1 running,   4 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   765684 total,   352760 free,   167580 used,   245344 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   562208 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND           
    1 root      20   0    1428    384    340 S   0.0  0.1   0:00.20 sh                
   17 root      20   0    4724   1692   1468 S   0.0  0.2   0:00.01 cron              
   20 root      20   0    4612   2296   2132 S   0.0  0.3   0:00.01 bash              
   21 root      20   0    4620   2596   2220 S   0.0  0.3   0:00.13 bash  

Any idea where to go from here?

@Medistream, to do a hardware test, could you try running this project on your device and see if it works ok?

@dansku Thanks I’ve tried that. It’s not a hardware issue I have 35 Pi’s to work with here :slight_smile:

I seem to have a fix for it.

I’m not too familiar with X window system stuff more of a web dev. If I understand the problem properly. The display is blocked by being in use and if it doesn’t properly shut down it creates a lock file to prevent a user from accessing it?

I added

# Remove X lock
sudo rm /tmp/.X0-lock

to the entrypoint file and it seems to have fixed it. I’ve tried rebooting and pushing about 20 times and it looks good here. Is there anything I should be aware of with this?

1 Like

@Medistream that is great, thanks for reporting back!

Nothing that I can think at the moment that you should be aware of. But if you encounter any other issues please let us know!

All the best!