Question

I have an embedded Linux board that uses systemd for startup processes. I also have a GUI written in Qt that I can launch just fine from the command line and interact with using the board's touchscreen or buttons. To launch the app I usually do:

ssh root@192.168.1.2
cd ~/
./gui

I'd like this to startup automatically using SystemD so I wrote a service file that looks like this:

[Unit]
Description=The Qt Gui
After=dropbear.service systemd-logind.service
ConditionFileIsExecutable=/home/user/gui

[Service]
ExecStart=/home/user/gui
Restart=on-abort

[Install]
WantedBy=multi-user.target

When the board boots I see in the systemd log that it is starting my gui right after the dropbear SSH service:

[  OK  ] Started Dropbear SSH2 daemon.
         Starting The Qt Gui...
[  OK  ] Started The Qt Gui. 

And if I SSH to the board after it boots and run 'ps' I can see my process started ( and if I kill it it restarts as expected from systemd ):

196 root     26868 S    /home/user/gui

The output of systemctl status looks OK to me, notice the last line 'ARM build' is a qDebug() print statement from my code:

gui.service - The Qt Gui
      Loaded: loaded (/etc/systemd/system/gui.service; enabled)
      Active: active (running) since Tue, 2012-11-20 21:30:20 UTC; 4min 35s ago
    Main PID: 196 (gui)
      CGroup: name=systemd:/system/gui.service
          └ 196 /home/user/gui

Nov 20 21:30:20 systemd[1]: Starting The Qt Gui...
Nov 20 21:30:20 systemd[1]: Started The Qt Gui.
Nov 20 21:30:22 gui[196]: ARM build

However I can not interact at all with the instance of the GUI being launched using systemd! If I launch a secondary instance from the command line than I can press buttons or the touchscreen and the GUI pops up on the screen and works as expected. What gives? I've tried 'Type=forking' in the service file and this doesn't help either. Any ideas on what is wrong here? How can I get systemd to launch my Qt GUI just as if I did it from the command line? Thanks -

Was it helpful?

Solution

Thanks for the input above. It actually was not a working directory or timing issue. The problem was that my Qt GUI was not getting the proper environment variables that it needed for communicating with the touchscreen. Sourcing /etc/profile worked for me:

[Unit]
Description=The Qt Gui
After=dropbear.service
ConditionFileIsExecutable=/home/user/gui

[Service]
Type=simple
TimeoutStartSec=60
WorkingDirectory=/home/user
ExecStartPre=/bin/sh -c 'echo 127 > /sys/class/backlight/generic-bl/brightness'
ExecStart=/bin/sh -c 'source /etc/profile ; /home/user/gui -qws'
Restart=always

[Install]
WantedBy=multi-user.target
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top