systemd service doesn't autostart
boarush opened this issue · 47 comments
➜ ~ libinput-gestures -l
libinput-gestures: session i3+x11 on Linux-5.12.6-arch1-1-x86_64-with-glibc2.33, python 3.9.5, libinput 1.17.2
Hash: f65598f0245115fca63c2a8cac5e0fce
Gestures configured in /etc/libinput-gestures.conf:
swipe up _internal ws_up
swipe down _internal ws_down
swipe left xdotool key alt+Right
swipe right xdotool key alt+Left
pinch in xdotool key super+s
pinch out xdotool key super+s
libinput-gestures: device /dev/input/by-path/pci-0000:00:15.0-platform-i2c_designware.0-event-mouse(event8): SYNA328B:00 06CB:CD50 Touchpad
libinput-gestures is installed.
libinput-gestures is set up as a user service.
libinput-gestures is not currently running.
libinput-gestures is set to autostart as a user service.
libinput-gestures is using default configuration.
systemd service won't autostart, but will start using libinput-gestures-setup start or systemctl --user start libinput-gestures.service will work.
Status reported by systemctl of libinput-gestures.service after boot is:
➜ ~ systemctl --user status libinput-gestures.service
○ libinput-gestures.service - Actions gestures on your touchpad using libinput
Loaded: loaded (/usr/lib/systemd/user/libinput-gestures.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Docs: https://github.com/bulletmark/libinput-gestures
After running libinput-gestures-setup start,
➜ ~ libinput-gestures-setup start
libinput-gestures started as a user service.
➜ ~ journalctl -b --user -u libinput-gestures
-- Journal begins at Wed 2021-04-21 12:13:28 IST, ends at Mon 2021-05-24 16:08:26 IST. --
May 24 16:08:26 Arch systemd[1009]: Started Actions gestures on your touchpad using libinput.
I released a new version today which makes some small changes that may affect this. You are using that version and your report is pretty clear. It seems to be stopping on startup, presumably due to an error but no error in reported in your journal which is the odd thing. The service runs fine for me after reboot.
Can you please reboot and (before you do anything else, i.e. restart it etc) then tell me the output of ls -l /tmp/libinput-gestures*?
Also, can you suggest anything unique about your system? We are both using Arch and both using a systemd user session to start this so I can't imagine why you would being seeing a problem that I am not? Another thing - does this happen after every reboot, or is it intermittent?
➜ ~ ls -l /tmp/libinput-gestures*
zsh: no matches found: /tmp/libinput-gestures*
I believe it has something to do with graphical-session.target and found this on stackexchange: Enabled systemd user service doesn't start at login
I can see that graphical-session.target doesn't start (or more appropriately, it is loaded, but not active) in my case (i3-gaps), and probably the case with other tiling window managers (only speculating).
And yes, the service won't autostart after every reboot. However after starting it manually, it will work normally as it should.
So it seems this has nothing to do with the changes I made today. So have you just started using libinput-gestures for the first time today? Or have you just changed it from a desktop app to a user session app?
Seems I just need to change the targets specified in the service file to something more generic.
After today's update, I changed it from a desktop app to user session app. I did try enabling the user systemd service before this update, but figured something was wrong with my system and didn't bother reporting the issue.
Can you please edit /usr/lib/systemd/user/libinput-gestures.service and change the last line:
-WantedBy=graphical-session.target
+WantedBy=default.target
The reboot and let me know if it works.
No, it isn't working after changing the last line to default.target.
Can you please paste the output of systemctl --user list-units --type target.
➜ ~ systemctl --user list-units --type target
UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
default.target loaded active active Main User Target
paths.target loaded active active Paths
sockets.target loaded active active Sockets
timers.target loaded active active Timers
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
5 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
Please edit /usr/lib/systemd/user/libinput-gestures.service and change the 3 occurrences of graphical-session.target to default.target. Then reboot.
The service would start, but now gestures won't work.
➜ ~ libinput-gestures -l
libinput-gestures: session i3+x11 on Linux-5.12.6-arch1-1-x86_64-with-glibc2.33, python 3.9.5, libinput 1.17.2
Hash: f65598f0245115fca63c2a8cac5e0fce
Gestures configured in /etc/libinput-gestures.conf:
swipe up _internal ws_up
swipe down _internal ws_down
swipe left xdotool key alt+Right
swipe right xdotool key alt+Left
pinch in xdotool key super+s
pinch out xdotool key super+s
libinput-gestures: device /dev/input/by-path/pci-0000:00:15.0-platform-i2c_designware.0-event-mouse(event8): SYNA328B:00 06CB:CD50 Touchpad
libinput-gestures is installed.
libinput-gestures is set up as a user service.
libinput-gestures is currently running as a user service.
libinput-gestures is set to autostart as a user service.
libinput-gestures is using default configuration.
➜ ~ systemctl --user status libinput-gestures.service
● libinput-gestures.service - Actions gestures on your touchpad using libinput
Loaded: loaded (/usr/lib/systemd/user/libinput-gestures.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2021-05-24 18:08:15 IST; 44s ago
Docs: https://github.com/bulletmark/libinput-gestures
Main PID: 1009 (python3)
Tasks: 4 (limit: 18820)
Memory: 22.3M
CPU: 392ms
CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/libinput-gestures.service
├─1009 python3 /usr/bin/libinput-gestures
└─1160 libinput-debug-events --device /dev/input/by-path/pci-0000:00:15.0-platform-i2c_designware.0-event-mouse
May 24 18:08:40 Arch libinput-gestures[1650]: Error: Can't open display: (null)
May 24 18:08:40 Arch libinput-gestures[1650]: Failed creating new xdo instance
May 24 18:08:40 Arch libinput-gestures[1651]: Error: Can't open display: (null)
May 24 18:08:40 Arch libinput-gestures[1651]: Failed creating new xdo instance
May 24 18:08:42 Arch libinput-gestures[1652]: Error: Can't open display: (null)
May 24 18:08:42 Arch libinput-gestures[1652]: Failed creating new xdo instance
May 24 18:08:42 Arch libinput-gestures[1654]: Error: Can't open display: (null)
May 24 18:08:42 Arch libinput-gestures[1654]: Failed creating new xdo instance
May 24 18:08:43 Arch libinput-gestures[1655]: Error: Can't open display: (null)
May 24 18:08:43 Arch libinput-gestures[1655]: Failed creating new xdo instance
Yes, I kind of expected that :(.
Please use libinput-gestures-setup stop desktop autostart start until I work out the best way to address this systemd issue.
@msourabh24 how are you starting i3-gaps?
I use lightdm as my display manager and it starts the i3 session.
Same issue with the on Manjaro KDE. I use desktop option without any problem. It's fine by me but I saw this issue and wanted to give some extra background. More details about my system:
Libinput-gestures: 2.67-1
OS: Manjaro 21.1.0 Pahvo
Kernel: x86_64 Linux 5.13.1-3-MANJARO
DE: KDE 5.84.0 / Plasma 5.22.3
@KaratasFurkan please paste here the output of libinput-gestures -l.
Sure,
libinput-gestures: session unknown+unknown on Linux-5.13.1-3-MANJARO-x86_64-with-glibc2.33, python 3.9.6, libinput 1.18.0
Hash: 7b225afc6809da81d306436673af8a29
Gestures configured in ~/.config/libinput-gestures.conf:
swipe up 3 xdotool key alt+Escape
swipe down 3 xdotool key super+Page_Down
swipe left 3 _internal --wrap ws_up
swipe right 3 _internal --wrap ws_down
swipe up 4 xdotool key super+Escape
swipe down 4 xdotool key super+alt+Page_Down
swipe left 4 xdotool key super+ctrl+n
swipe right 4 xdotool key super+ctrl+p
libinput-gestures: device /dev/input/by-path/platform-i8042-serio-1-event-mouse(event12): SynPS/2 Synaptics TouchPad
libinput-gestures is installed.
libinput-gestures is set up as a desktop application.
libinput-gestures is currently running as a desktop application.
libinput-gestures is set to autostart as a desktop application.
libinput-gestures is using custom configuration file.
@KaratasFurkan that shows you must be using an odd/unique way to start your desktop. How are you starting it?
I didn't understand what you mean 🤔 I just power on my laptop and boot Manjaro KDE as usual.
But how do you start Plasma? Do you use a display manager? Or, do you start it by hand, or from ~/.xinitrc etc? Do you use Wayland?
I'm sorry, I don't know. I use default Manjaro KDE without any advanced configuration. This is my .xinitrc which I didn't touch, it may help:
#!/bin/bash
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)
userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap
DEFAULT_SESSION=startplasma-x11
# merge in defaults and keymaps
if [ -f $sysresources ]; then
xrdb -merge $sysresources
fi
if [ -f $sysmodmap ]; then
xmodmap $sysmodmap
fi
if [ -f "$userresources" ]; then
xrdb -merge "$userresources"
fi
if [ -f "$usermodmap" ]; then
xmodmap "$usermodmap"
fi
# start some nice programs
if [ -d /etc/X11/xinit/xinitrc.d ] ; then
for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
[ -x "$f" ] && . "$f"
done
unset f
fi
get_session(){
local dbus_args=(--sh-syntax --exit-with-session)
case $1 in
awesome) dbus_args+=(awesome) ;;
bspwm) dbus_args+=(bspwm-session) ;;
budgie) dbus_args+=(budgie-desktop) ;;
cinnamon) dbus_args+=(cinnamon-session) ;;
deepin) dbus_args+=(startdde) ;;
enlightenment) dbus_args+=(enlightenment_start) ;;
fluxbox) dbus_args+=(startfluxbox) ;;
gnome) dbus_args+=(gnome-session) ;;
i3|i3wm) dbus_args+=(i3 --shmlog-size 0) ;;
jwm) dbus_args+=(jwm) ;;
kde) dbus_args+=(startplasma-x11) ;;
lxde) dbus_args+=(startlxde) ;;
lxqt) dbus_args+=(lxqt-session) ;;
mate) dbus_args+=(mate-session) ;;
xfce) dbus_args+=(xfce4-session) ;;
openbox) dbus_args+=(openbox-session) ;;
*) dbus_args+=($DEFAULT_SESSION) ;;
esac
echo "dbus-launch ${dbus_args[*]}"
}
exec $(get_session "$1")
xset r rate 250 60
I don't think that I use wayland but i'm not sure.
Sorry, I use Arch and have never looked at Manjaro. Looking just now, I see you actually install from a complete pre-built Manjaro + KDE iso which is quite unlike Arch where you install a base system then install whatever DM and DE you want.
Anyhow, it seems the environment is probably exhibiting same/similar problem as OP here. Can you please paste the output of systemctl --user list-units --type target.
systemctl --user list-units --type target UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
bluetooth.target loaded active active Bluetooth
default.target loaded active active Main User Target
paths.target loaded active active Paths
sockets.target loaded active active Sockets
timers.target loaded active active Timers
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
6 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
@KaratasFurkan please paste the output of systemctl --user status graphical-session.target and systemctl --user show graphical-session.target. When pasting output, please always include the command.
@msourabh24 can you please also paste the output of the 2 commands:
systemctl --user status graphical-session.target
systemctl --user show graphical-session.target
systemctl --user status graphical-session.target
○ graphical-session.target - Current graphical user session
Loaded: loaded (/usr/lib/systemd/user/graphical-session.target; static)
Active: inactive (dead)
Docs: man:systemd.special(7)
systemctl --user show graphical-session.target
Id=graphical-session.target
Names=graphical-session.target
Requires=basic.target
ConsistsOf=plasma-kglobalaccel.service plasma-kactivitymanagerd.service
Conflicts=shutdown.target
Before=shutdown.target
After=basic.target
Documentation="man:systemd.special(7)"
Description=Current graphical user session
LoadState=loaded
ActiveState=inactive
FreezerState=running
SubState=dead
FragmentPath=/usr/lib/systemd/user/graphical-session.target
UnitFileState=static
UnitFilePreset=enabled
StateChangeTimestampMonotonic=0
InactiveExitTimestampMonotonic=0
ActiveEnterTimestampMonotonic=0
ActiveExitTimestampMonotonic=0
InactiveEnterTimestampMonotonic=0
CanStart=no
CanStop=yes
CanReload=no
CanIsolate=no
CanFreeze=no
StopWhenUnneeded=yes
RefuseManualStart=yes
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=yes
OnFailureJobMode=replace
IgnoreOnIsolate=no
NeedDaemonReload=no
JobTimeoutUSec=infinity
JobRunningTimeoutUSec=infinity
JobTimeoutAction=none
ConditionResult=no
AssertResult=no
ConditionTimestampMonotonic=0
AssertTimestampMonotonic=0
Transient=no
Perpetual=no
StartLimitIntervalUSec=10s
StartLimitBurst=5
StartLimitAction=none
FailureAction=none
SuccessAction=none
CollectMode=inactive
@bulletmark Here's the output:
➜ ~ systemctl --user status graphical-session.target
○ graphical-session.target - Current graphical user session
Loaded: loaded (/usr/lib/systemd/user/graphical-session.target; static)
Active: inactive (dead)
Docs: man:systemd.special(7)
➜ ~ systemctl --user show graphical-session.target
Id=graphical-session.target
Names=graphical-session.target
Requires=basic.target
Conflicts=shutdown.target
Before=shutdown.target
After=basic.target
Documentation="man:systemd.special(7)"
Description=Current graphical user session
LoadState=loaded
ActiveState=inactive
FreezerState=running
SubState=dead
FragmentPath=/usr/lib/systemd/user/graphical-session.target
UnitFileState=static
UnitFilePreset=enabled
StateChangeTimestampMonotonic=0
InactiveExitTimestampMonotonic=0
ActiveEnterTimestampMonotonic=0
ActiveExitTimestampMonotonic=0
InactiveEnterTimestampMonotonic=0
CanStart=no
CanStop=yes
CanReload=no
CanIsolate=no
CanFreeze=no
StopWhenUnneeded=yes
RefuseManualStart=yes
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=yes
OnSuccesJobMode=fail
OnFailureJobMode=replace
IgnoreOnIsolate=no
NeedDaemonReload=no
JobTimeoutUSec=infinity
JobRunningTimeoutUSec=infinity
JobTimeoutAction=none
ConditionResult=no
AssertResult=no
ConditionTimestampMonotonic=0
AssertTimestampMonotonic=0
Transient=no
Perpetual=no
StartLimitIntervalUSec=10s
StartLimitBurst=5
StartLimitAction=none
FailureAction=none
SuccessAction=none
CollectMode=inactive
I also have the same problem.
My system is Arch+SDDM+KDE. The display manager is started by systemctl enable sddm.service.
The graphical-session.target is inactive. I found an issue regarding graphical-session.target not being activated on sddm's github. They claim it's not their responsibility to start the target. May be some other display mangers start the target, but SDDM does not. But KDE itself has an option (off by default) to start itself using systemd user instance (see)
kwriteconfig5 --file startkderc --group General --key systemdBoot true
but as stated here and here this method of KDE startup might introduce some issues, and indeed my HiDPI stopped working on GTK applications after I enabled the option, although it solved the issue of auto-starting libinput-gestures as systemd user service.
I think it would be good to update the README.md page to mention, that systemd user service method just does not work with some DM+DE configurations.
well I'm having the same problem, too @bulletmark , but since i use plasma, i created simple solution by creating sh extension files then registering on autostart on plasma.
for the sh file i give the name libinput-start.sh and commands like this
#!/bin/bash
libinput-gestures-setup start &and on autostart plasma
maybe this may can help anyone
@ypraw, sorry that is a poor "solution". Anybody who can not use the systemd service start option should just use the desktop start option.
Same issue here on Arch + bspwm.
❯ libinput-gestures -l
libinput-gestures: session bspwm+x11 on Linux-5.15.4-arch1-1-x86_64-with-glibc2.33, python 3.9.7, libinput 1.19.2
Hash: d345053aa987bdaf6d510359a4e72fd1
Gestures configured in ~/.config/libinput-gestures.conf:
swipe up _internal ws_up
swipe down _internal ws_down
swipe left _internal ws_up
swipe right _internal ws_down
pinch in xdotool key ctrl+minus
pinch out xdotool key ctrl+plus
libinput-gestures: device /dev/input/by-path/pci-0000:00:15.1-platform-i2c_designware.1-event-mouse(event16): DLL0945:00 06CB:CDE6 Touchpad
libinput-gestures is installed.
libinput-gestures is set up as a desktop application.
libinput-gestures is not currently running.
libinput-gestures is not set to autostart.
libinput-gestures is using custom configuration file.
❯ systemctl --user list-units --type target
UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
bluetooth.target loaded active active Bluetooth
default.target loaded active active Main User Target
paths.target loaded active active Paths
sockets.target loaded active active Sockets
timers.target loaded active active Timers
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
6 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
@bulletmark I fixed this issue by removing the first two instances of graphical-session.target (completely deleting the line) and changing the target to default.target, but used systemctl --user enable libinput-gestures to make it start only after I entered a user session (so the display server is definitely running at this point)
so this is what my service file looks like now
[Unit]
Description=Actions gestures on your touchpad using libinput
Documentation=https://github.com/bulletmark/libinput-gestures
[Service]
Type=simple
ExecStart=/usr/bin/libinput-gestures
[Install]
WantedBy=default.target@obj-obj, please read over the history of this bug above. The default target works for some (e.g. me) but not for others because it all depends on the timing of your system, i.e. it's random. The point of WantedBy=graphical-session.target is to guarantee starting after your DE but it seems some DE's/distros don't provide that, or don't implement it correctly.
@bulletmark ah, sorry. I only read the first 10 or so comments and skimmed through the rest
I think I've figured out how to handle this in i3!
First, create a new file at ~/.config/systemd/user/i3-session.target:
[Unit]
Description=i3 session
BindsTo=graphical-session.targetNext, edit your i3 config to include exec --no-startup-id systemctl --user start i3-session.target.
After restarting i3 (or rebooting) you should see that graphical-session.target is active:
$ systemctl --user status graphical-session.target
● graphical-session.target - Current graphical user session
Loaded: loaded (/usr/lib/systemd/user/graphical-session.target; static)
Active: active since Wed 2022-02-02 22:34:16 PST; 34min ago
Until: Wed 2022-02-02 22:34:16 PST; 34min ago
Docs: man:systemd.special(7)
Feb 02 22:34:16 theraft systemd[1320]: Reached target Current graphical user session.Finally, you should be able to run libinput-gestures-setup service autostart to tell systemd to start libinput-gestures along with i3. Huzzah!
(Extra info below, based on my googling).
graphical-session.target is a special systemd target that's meant to be a more generic way for applications to say "start me whenever the GUI is up and the user has logged in". Without it, applications would have to say "start me whenever KDE starts up, or GNOME starts up, or i3 starts up, or ..."
As for who is actually responsible for starting this target, it's not very clear. Based on this issue, it doesn't seem to be the login/display manager's job. However, I also couldn't find it mentioned anywhere in terms of i3 supporting it. It looks like it's up to the user, unless your DE supports it?
@jamiesyme Thanks for this solution! Can surely confirm this works on my system and I don't have to deal with .desktop files anymore.
hi
i'm still getting this on xfce + archlinux + lightdm "systemd not available"
i started it as a desktop app for now though.
@arjunkathuria do you mean you are getting the error message "Systemd not available, can not run as service"? Please be exact when reporting error messages.
Yes. Here's the command i tried and the output
$ libinput-gestures-setup service
Systemd not available, can not run as service.
@arjunkathuria, as discussed above, that's because your environment does not have the systemd graphical-session.target available so there is no way to guarantee that libinput-gestures can be started reliably. Run it using the desktop option.
i know this issue is about systemd service, but i do think it's worth to add this side note.
with archlinux, i3wm, lightdm, i think the simplest solution is "don't run libinput-gestures as systemd service, instead, start it via i3wm config exec --no-startup-id libinput-gestures".
the readme says libinput-gestures-setup all alone, i think that's why some (maybe a lot?) people faced this problem.
@haolian9, not sure what you are saying. Does libinput-gestures-setup stop desktop autostart start not work for you?
I have used the systemd user option to start since the option was added and it was always worked reliably for me. However, for the last couple of months (maybe since GNOME 42 but I think before) I find that occasionally after some reboots the app will not receive commands, even on my vanilla GNOME system. So I have given up on that option and have depreciated it in the README with commit a3711c1 and new version 2.73. Users should simply use the default desktop start option. I am closing this bug because I am not really supporting the service option any more, although note I have left the option in the code for users that really want to persevere with it.
for me it autostart at boot but cannot after log out / log in.
same settings and configs but why this?
@linuxtopia that because you have to sudo loginctl enable-linger $USER. See section 2.2 of https://wiki.archlinux.org/title/Systemd/User#Basic_setup.