How to open a qml interface using systemd? - qt

I want to open a qml interface using systemd and when the user closes the window, the system automatically restarts the process to open the window again, but the interface doesn't open.
I tried this configuration:
[Unit]
Description=test
After=graphical.target
Wants=graphical.target
[Service]
Type=simple
ExecStart=~/test
Restart=on-failure
RestartSec=10
KillMode=process
[Install]
WantedBy=multi-user.target
Alias=test.Service
test is my binary, that runs my qml interface.
How can I do this?
Please if possible provide an example for my case.

Related

Running nobody (or dynamic user) with CAP_NET_RAW in systemd

I want to run service with cap_net_raw capabilities but with no any interaction with filesystem and/or other processes. My program will use raw sockets and normal sockets (for API), stdout/err for logging and that's all.
I want to write systemd.service file to do this, but I couldn't produce a proper combination for DynamicUser, User and CapabilityBoundingSet.
My (non-working) unit looks like this:
[Unit]
Description=my daemon (%I)
ConditionFileNotEmpty=/etc/daemon/%i.conf
Wants=network-online.target
BindsTo=daemon.target
[Service]
Type=simple
WorkingDirectory=/etc/daemon
EnvironmentFile=/etc/daemon/%i.conf
ExecStart=/usr/bin/daemon ${OPTIONS}
CapabilityBoundingSet=CAP_NET_RAW
ProtectSystem=true
ProtectHome=true
RestartSec=5s
Restart=on-failure
User=daemon-%i
Group=nobody
DynamicUser=true
[Install]
WantedBy=daemon.target
How can I configure dynamic user 'nobody' together with CAP_NET_RAW?
You also need:
AmbientCapabilities=CAP_NET_RAW
See this question about the difference between AmbientCapabilities and CapabilityBoundingSet, as well as the documentation.

Camera (/dev/video0) dependencies in systemd service Ubuntu 16.04

I need to run some services on boot up which I have successfully accomplished using systemd services. (Lots of answers already available).
Now, one of my service requires access to /dev/video0 while bootup when a certain user is logged in. (I am doing auto login which is working fine).
So how do I check that whether the /dev/video0 is available before starting my systemd service while bootup.
I came across something called udev for doing this, I followed this link
but I am not getting desired output as after editing /lib/udev/rules.d/99-systemd.rules files as mentioned in the link and starting my service manually it's not starting, any help is appreciated.
Finally after struggling for a day I found the answer -
I made a script in /etc/systemd/system which contains
[Unit]
Description='some description of my file write according to you'
[Service]
Type=forking
ExecStart='path to script'
[Install]
WantedBy=multi-user.target
and It executes a script which contains
#!/bin/bash
modprobe uvcvideo
Now after rebooting all the services are running properly
mod probe uvcvideo command check for running video driver and enable it at the time of bootup so that It is available for my systemd process
Thanks

systemd execute after a oneshot service

Hi is it possible to run a service after a "oneshot" type service
I want to run a script that started before display-manager.service but after gpu-manager.service, gpu-manager.service is a oneshot service that detect available gpu. This is my service :
[Unit]
After=gpu-manager.service
Before=display-manager.service
[Service]
Type=oneshot
ExecStart=myscript
[Install]
WantedBy=multi-user.target
Will my service be started after gpu-manager and before display started ?
Are you sure that you need 3 services?
You can use ExecStop or other directives to run multiple scripts and use 1 systemd service.
Try this solution
[Unit]
Description=example
[Service]
Type=oneshot
ExecStart=/usr/local/bin/on_start.sh
RemainAfterExit=true
ExecStop=/usr/local/bin/with_stopped.sh
[Install]
WantedBy=graphical.target

How to start services in early stage of beaglebone boot?

I am trying to change the Beaglebone black splash screen.
I am using Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.06.20.img.xz image.
I compiled the psplash source (as explained in https://groups.google.com/forum/#!msg/beagleboard/HRDjAtsPO68/dc7gIZTynQkJ) and now psplash works fine.
In order to automatically start psplash I create a new system service called psplash.service and I enabled it with the command "systemctl enable psplash.service".
The problem is: when Beaglebone boots, the psplash is launched a little bit late and you can see for several
seconds the standard beaglebone logo. How can I configure the service in order to run the psplash as soon as possible ?
Is there a better way than the system services for starting psplash program ?
Here is the system service file:
[Unit]
Description=Splash screen
[Service]
WorkingDirectory=/home/root/
ExecStart=/usr/local/bin/psplash
SyslogIdentifier=psplash
[Install]
WantedBy=multi-user.target
Systemd services by default have dependencies so removing the dependencies will allow it to start the service early.
[Unit]
Description=Splash screen
DefaultDependencies=no
[Service]
Type=oneshot
ExecStart=/usr/local/bin/psplash
[Install]
WantedBy=basic.target
This will cause it to start before other dependencies. You may add dependencies within the [Unit] block with After=... or Before=.... But be careful with the Before=... as it will wait for psplash to end and since psplash will run uninterrupted on its own it may cause start-up to hang.
This will cause the service to run earlier in the systemd process but I am still looking into other ways to get it to start even earlier.

Qt GUI instance autostarted with systemd does not respond to input

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 -
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

Resources