Delay startup of deCONZ in GUI mode on Pi until after X server is active.

[ebaauw]

trafficstars

As described in #1736, the deCONZ GUI crashes when started before the X server is running. If that happens too often during startup of the Pi, systemctl gives up. The suggested workaround by introducing a timer works for me, but might delay the startup of deCONZ longer than needed.

I found another solution to this issue, see the last contribution on: https://superuser.com/questions/759759/writing-a-service-that-depends-on-xorg

The trick is to wait for the X server to create the /tmp/.X11-unix/X0 socket. A simple shell script, executed as ExecStartPre suffices. The setup below works on my Pi 3B+ running Stretch and on my Pi 4B running Buster.

@manup, @ChrisHae could you include something like this in the deCONZ distribution?

Slighly related:

• Would it be possible to include the changes from override.conf in deconz-gui.service and deconz.service, so systemctl would no longer bitch about needing a daemon-reload every time the Pi is rebooted. The installation would have to create /etc/defaults/deconz if it doesn't already exist, but leave it alone if it does.
• Would it be possible to fix deCONZ-init.sh so it only enables the deconz-wifi service when running from the Phoscon SD card image? See also #1994.
• It seemsdeconz-gui.service has an error:

  [/lib/systemd/system/deconz-gui.service:11] Unknown lvalue 'StartLimitIntervalSec' in section 'Service'
  

$ cat /usr/bin/deCONZ-wait-for-X.sh 
#!/bin/bash
# Wait for X server to start.

LOG_ERROR="<3>"
LOG_INFO="<6>"

for ((i = 0; i < 120; i++)) ; do
  if [ -S /tmp/.X11-unix/X0 ] ; then
    echo "${LOG_INFO}X server started."
    sleep 2
    exit 0
  fi
  if ((i % 5 == 0)) ; then
    echo "${LOG_INFO}Waiting for X server to start..."
  fi
  sleep 1
done
echo "${LOG_ERROR}X server not started after ${i} seconds. Giving up."
exit 1

$ cat /etc/systemd/system/deconz-gui.service.d/override.conf 
[Service]
EnvironmentFile=/etc/default/deconz
ExecStart=
ExecStart=/usr/bin/deCONZ $DECONZ_OPTS
ExecStartPre=/usr/bin/deCONZ-wait-for-X.sh

$ cat /etc/default/deconz 
# DECONZ_OPTS="--http-port=80 --upnp=0 --dbg-info=2 --dbg-aps=2 --dbg-zcl=1 --dbg-zdp=1 --dbg-http=1 --dbg-error=1"

DECONZ_OPTS="--dev=/dev/ttyACM0 --http-port=8008 --dbg-info=2 --dbg-aps=2 --dbg-error=1"

[ebaauw]

Analysing the logs, the dependency on the VNC server almost seems to work; there's only a 1-2 second mismatch between the start of the VNC server and the X server being available. Note that I still do sleep 2 after the socket has been found.

Maybe a simpleExecStartPre=/bin/sleep 3 would suffice, but that wouldn't work if the VNC service is disabled. Not sure how many people would use a Pi as desktop computer without VNC, though.

On the Pi 4B:

Feb 22 23:16:20 pi5 deCONZ-wait-for-X.sh[754]: Waiting for X server to start...
Feb 22 23:16:20 pi5 vncserver-x11[736,root]: ServerManager: Server started
Feb 22 23:16:20 pi5 vncserver-x11[736,root]: ConsoleDisplay: Cannot find a running X server on vt1
Feb 22 23:16:20 pi5 vncserver-x11[736,root]: ConsoleDisplay: Found running X server (pid=751, binary=/usr/lib/xorg/Xorg)
Feb 22 23:16:21 pi5 deCONZ-wait-for-X.sh[754]: X server started.
Feb 22 23:16:23 pi5 systemd[1]: Started deCONZ: ZigBee gateway -- GUI/REST API.

On the Pi 3B+:

Feb 22 23:09:06 pi1 vncserver-x11[593,root]: ServerManager: Server started
Feb 22 23:09:06 pi1 deCONZ-wait-for-X.sh[624]: Waiting for X server to start...
Feb 22 23:09:06 pi1 vncserver-x11[593,root]: ConsoleDisplay: Cannot find a running X server on vt1
Feb 22 23:09:06 pi1 vncserver-x11[593,root]: ConsoleDisplay: Found running X server (pid=623, binary=/usr/lib/xorg/Xorg)
Feb 22 23:09:07 pi1 deCONZ-wait-for-X.sh[624]: X server started.
Feb 22 23:09:09 pi1 systemd[1]: Started deCONZ: ZigBee gateway -- GUI/REST API.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ebaauw]

Bump

[carrodcor]

There's an easier way: get it started by the GUI.

sudo cp /usr/share/applications/deCONZ.desktop  /etc/xdg/autostart
sudo chmod 755 /etc/xdg/autostart/deCONZ.desktop
sudo reboot

[Sjonnie2018]

Might be coincidence but after applying the "fix" from @carrodcor I lost all my connected lights. Switches and sensors were still there though. Unable to remedy the error I now only have to re-enable some 30 lights to get things working again :| I must have done something wrong but it is advised to know what you're doing (make another back-up just to be sure !)

[ebaauw]

I find my workaround now fails, and causes deCONZ to crash on the first attempt. Not sure if that's due to changes to PiOS, or changes in deCONZ startup sequence.

Changing the sleep 2 before the exit 0 to sleep 3 seems to do the trick.

[manup]

I find my workaround now fails, and causes deCONZ to crash on the first attempt. Not sure if that's due to changes to PiOS, or changes in deCONZ startup sequence.

Changing the sleep 2 before the exit 0 to sleep 3 seems to do the trick.

With #6852 merged should this issue now be closed, or do we need better solution to check fox X being up (and likely Wayland)?

[ebaauw]

The solution described here requires the user to create an override.conf file. You might consider integrating this in the deconz-gui.service. And while we’re at this, fix #2771 as well. I would have created a PR for this, but the .service files aren’t part of the REST API plugin repo.