xinit: giving up timeout in container using X


I have a ‘display’ service that drives a tablet screen that is started as part of the service stack on my edge device (Dell 7212 tablet) running the NUC BOS variant. This container takes ~3m to ‘boot’, all other services work fine

[Logs]    [12/23/2019, 8:56:57 AM] [display] ..
[Logs]    [12/23/2019, 8:56:59 AM] [display] ..
[Logs]    [12/23/2019, 8:57:01 AM] [display] ..
[Logs]    [12/23/2019, 8:57:03 AM] [display] ..
[Logs]    [12/23/2019, 8:57:05 AM] [display] ..
[Logs]    [12/23/2019, 8:57:07 AM] [display] ..
[Logs]    [12/23/2019, 8:57:09 AM] [display] ..
[Logs]    [12/23/2019, 8:57:11 AM] [display] ..
[Logs]    [12/23/2019, 8:57:13 AM] [display] ..
[Logs]    [12/23/2019, 8:57:13 AM] [display] xinit: giving up
[Logs]    [12/23/2019, 8:57:13 AM] [display] xinit: unable to connect to X server: Cannot assign requested address
[Logs]    [12/23/2019, 8:57:13 AM] [display] 
[Logs]    [12/23/2019, 8:57:13 AM] [display] waiting for X server to shut down (II) Server terminated successfully (0). Closing log file.
[Logs]    [12/23/2019, 8:57:14 AM] [display] xinit: server error
[Logs]    [12/23/2019, 8:57:14 AM] [display] 
[Logs]    [12/23/2019, 8:57:14 AM] Service exited 'display sha256:eb7576d8cccac59c4bb6c8aec537c01bb9910a8c672d2fcf9f089eff2d4d0601'
[Logs]    [12/23/2019, 8:57:16 AM] Restarting service 'display sha256:eb7576d8cccac59c4bb6c8aec537c01bb9910a8c672d2fcf9f089eff2d4d0601'
[Logs]    [12/23/2019, 8:57:14 AM] [display] 
[Logs]    [12/23/2019, 8:57:14 AM] [display] xinit: server error
[Logs]    [12/23/2019, 8:57:17 AM] [display] 
[Logs]    [12/23/2019, 8:57:17 AM] [display] 
[Logs]    [12/23/2019, 8:57:17 AM] [display] X.Org X Server 1.20.4
[Logs]    [12/23/2019, 8:57:17 AM] [display] X Protocol Version 11, Revision 0
[Logs]    [12/23/2019, 8:57:17 AM] [display] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[Logs]    [12/23/2019, 8:57:17 AM] [display] Current Operating System: Linux dce3584ab089 5.2.10-yocto-standard #1 SMP PREEMPT Fri Oct 4 11:58:01 UTC 2019 x86_64
[Logs]    [12/23/2019, 8:57:17 AM] [display] Kernel command line: BOOT_IMAGE=/boot/bzImage root=LABEL=resin-rootA rootwait intel_idle.max_cstate=1
[Logs]    [12/23/2019, 8:57:17 AM] [display] Build Date: 05 March 2019  08:11:12PM
[Logs]    [12/23/2019, 8:57:17 AM] [display] xorg-server 2:1.20.4-1 ( 
[Logs]    [12/23/2019, 8:57:17 AM] [display] Current version of pixman: 0.36.0
[Logs]    [12/23/2019, 8:57:17 AM] [display] 	Before reporting problems, check
[Logs]    [12/23/2019, 8:57:17 AM] [display] 	to make sure that you have the latest version.
[Logs]    [12/23/2019, 8:57:17 AM] [display] Markers: (--) probed, (**) from config file, (==) default setting,
[Logs]    [12/23/2019, 8:57:17 AM] [display] 	(++) from command line, (!!) notice, (II) informational,
[Logs]    [12/23/2019, 8:57:17 AM] [display] 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[Logs]    [12/23/2019, 8:57:17 AM] [display] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec 23 00:57:17 2019
[Logs]    [12/23/2019, 8:57:17 AM] [display] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[Logs]    [12/23/2019, 8:57:17 AM] [display] (II) modeset(0): Initializing kms color map for depth 24, 8 bpc.

Once it timeouts, it loads fine. Seems I have to make the container start dependent on some other system service perhaps ?

The salient parts of my run script:

export DISPLAY=:0.0
export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
startx /usr/local/bin/display

The Dockerfile

FROM balenalib/%%BALENA_ARCH%%-debian-python:3.7-buster-build

RUN install_packages \
  dbus-x11 \
  libsm6 \
  libxext6 \
  libxrender-dev \
  matchbox-keyboard \
  x11-xserver-utils \
  xinit \
  xserver-xorg \

RUN pip install display

COPY xserverrc /etc/X11/xinit/xserverrc

WORKDIR /root/

CMD ["bash", ""]


I have never tried this in a single-container mode; but in multi-container you need to add a label to the service in question for the host’s DBUS socket to be mounted inside. See

Looking at the error, and the fact that it does eventually start the service, could you provide some context to the content of xserverrc as it’s possible this is looking for something which doesn’t exits at the time. We have some example apps which use X11 display output in our playground; have you compared your setup against them?

OK, I assumed those are just special cases for when you don’t want to grant ‘global’ access. My compose snippet for that service is pretty run of the mill:

    build: ./display/
    privileged: true
    restart: always
      - mqtt


exec /usr/bin/X -s 0 dpms

My understanding is that the rc’s are called as part of X startup so above is called by startx… not super sure about that though.

I think most of the service is based on snippets I found in the playground yes.

OK so setting the -nolisten tcp parameter in the xserverrc script seems to do the trick. Makes sense I guess, you probably need to expose the X tcp port to allow connecting clients anyway - which is not something I need for this app.

exec /usr/bin/X -s 0 dpms -nolisten tcp "$@"

Thanks for the tip, mate :slight_smile: