Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use systemd to start fusuma at boot #52

Open
worldofpeace opened this issue Nov 15, 2017 · 14 comments
Open

Use systemd to start fusuma at boot #52

worldofpeace opened this issue Nov 15, 2017 · 14 comments

Comments

@worldofpeace
Copy link

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

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
Copy link
Author

worldofpeace commented Nov 21, 2017

@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
Copy link

yellowgh0st commented Dec 11, 2017

I think it's better to create [email protected] 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/[email protected]

[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 [email protected]

@z0rc
Copy link
Contributor

z0rc commented Jan 11, 2018

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

stale bot commented Apr 15, 2018

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.

@stale stale bot added the wontfix label Apr 15, 2018
@stale stale bot closed this as completed Apr 22, 2018
@rajeshisnepali
Copy link

I think it's better to create [email protected] template and then enable it for specific user.

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

@quantumgc
Copy link

quantumgc commented Mar 11, 2021

@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
Copy link

@quantumgc what about these patterns [email protected] and fusuma.service.

@quantumgc
Copy link

@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
Copy link

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

@videni
Copy link

videni commented Aug 20, 2021

@yellowgh0st , not working, error

failed to creating new xdo instance

@ch3n9w
Copy link

ch3n9w commented Oct 6, 2021

@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
Copy link

@ch4xer Same problem here.

@superpupervlad
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests