Use systemd to start fusuma at boot

[worldofpeace]

Currently the best way of starting fusuma is running fusuma & disown.
I would expect fusuma to automatically start on boot but it doesn't.

This is a simple as creating a systemd unit file.

[awlunsfo]

For example:

$ cat /etc/systemd/user/fusuma.service 
[Unit]
Description=Fusuma touchpad gestures

[Service]
EnvironmentFile=/home/youruser/config/fusuma/env
ExecStart=/usr/local/bin/fusuma
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
User=youruser
Group=yourusergroup

[Install]
WantedBy=multi-user.target

The contents of the environment file at /home/youruser/config/fusuma/env is just DISPLAY=:0, where youruser is your user account name.

Then sudo systemctl enable /etc/systemd/user/fusuma.service

[worldofpeace]

@awlunsfo Thanks for your response!

The only thing I think that will cause problems is ExecStart=/usr/local/bin/fusuma.
Everyone is getting ruby from different places and, they also could be using rvm, rbenv, etc.
You can run which fusuma and that will give you the path of fusuma.

Also I think it would make sense for this service to be created when you install fusuma.
So we'll have to make a template for the service and a script to setup fusuma.

[yellowgh0st]

I think it's better to create fusuma@.service template and then enable it for specific user.
When it's enabled this way %i becomes user so it's not necessary to write username into .service

Also DISPLAY=:0 can be set right in .service:

Here's my solution:

Create service file: /lib/systemd/system/fusuma@.service

[Unit]
Description=Fusuma multitouch gesture recognizer

[Service]
Type=simple
Environment="DISPLAY=:0"
User=%i
ExecStart=/usr/local/bin/fusuma
KillMode=process
Restart=on-failure
    
[Install]
WantedBy=graphical.target

Enable it for the user

systemctl enable fusuma@username.service

[z0rc]

Instead of creating system-wide unit for specific user, it's advised to create user's unit which is managed by systemctl --user. At this case you don't need to specify user under which you need to run the service and DISPLAY var is automatically set (if you distribution is sane enough). Hint: DISPLAY isn't always a :0.

[stale]

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.

[rajeshisnepali]

I think it's better to create fusuma@.service template and then enable it for specific user.

I don't know why specifying via template (fusuma@.service) worked and why just specifying just unit (fusuma.service) doesn't work.

[quantumgc]

@rajeshisnepali, @z0rc: Fusuma needs to run under the input group but systemd user services cannot change their group. Thus a Fusuma system service can run successfully since it'll run as root, but a user service will fail since it'll only run under the user's group and won't have access to the input devices.

One solution to this would be creating a system wide service file and shipping it with the program. I might do this for the AUR package.

[rajeshisnepali]

@quantumgc what about these patterns fusuma@.service and fusuma.service.

[quantumgc]

@rajeshisnepali: If I'm reading the thread correctly, the recommendation is to install both of those files in /usr/lib/systemd/system/ so they're not user service files. User service files are either installed in /usr/lib/systemd/user/ which installs them for every user (but they still run as user services) or in ~/.config/systemd/user for per-user files.

[rajeshisnepali]

for me saving in ~/.config/systemd/user didn't work. Neither in /usr/lib/systemd/user/. Only works if I'd name as fusuma@.service, not as fusuma.service

[videni]

@yellowgh0st ， not working, error

failed to creating new xdo instance

[ch3n9w]

@yellowgh0st thanks for you script, but i encounter a problem that i can not use qdbus command like qdbus org.kde.kglobalaccel /component/kwin invokeShortcut Expose with systemd service, but when i manully launch fusuma from terminal, the qdbus command works as expected.

[NikhilSaini38]

@ch4xer Same problem here.

[superpupervlad]

If your systemd fusuma config not working you can check logs with journalctl -u fusuma (or your name for service)
And if you have this error in logs

appmatcher doesn't support
XDG_CURRENT_DESKTOP: ''
XDG_SESSION_TYPE: ''"

Just add Environment="XDG_SESSION_TYPE=x11" to your systemd config. To check right values run echo $XDG_SESSION_TYPE