touchegg icon indicating copy to clipboard operation
touchegg copied to clipboard

Stops working on logout/login, or sometimes randomly

Open spikespaz opened this issue 2 years ago • 9 comments

Describe the bug

Occasionally I go to use a gesture and notice that it doesn't work. Then I try all of them, and nothing works. Sometimes this happens randomly, but it is guaranteed to happen after a logout/login.

Stopping and starting the systemd service does not seem to do much of anything.

Logs

$ touchegg --debug
...

When I do this, touchegg starts working normally, printing correct results to the terminal.

  • Version of Touchégg: Touchégg v2.0.12.
██████████████████  ████████   jacob@jacob-thinkpad 
██████████████████  ████████   -------------------- 
██████████████████  ████████   OS: Manjaro Linux x86_64 
██████████████████  ████████   Host: 20Y1S00C00 ThinkPad P14s Gen 1 
████████            ████████   Kernel: 5.15.7-1-MANJARO 
████████  ████████  ████████   Uptime: 7 hours, 43 mins 
████████  ████████  ████████   Packages: 1387 (pacman), 17 (snap) 
████████  ████████  ████████   Shell: zsh 5.8 
████████  ████████  ████████   Resolution: 1920x1080 
████████  ████████  ████████   DE: Cinnamon 5.0.7 
████████  ████████  ████████   WM: Mutter (Muffin) 
████████  ████████  ████████   WM Theme: Mint-Y-Dark-Aqua (Adapta-Maia) 
████████  ████████  ████████   Theme: Mint-Y-Dark-Aqua [GTK2/3] 
████████  ████████  ████████   Icons: Papirus-Dark-Maia [GTK2/3] 
                               Terminal: gnome-terminal 
                               CPU: AMD Ryzen 7 PRO 4750U with Radeon Graphics (16) @ 1.700GHz 
                               GPU: AMD ATI 07:00.0 Renoir 
                               Memory: 5767MiB / 21809MiB 

spikespaz avatar Jan 04 '22 18:01 spikespaz

I've been experiencing exactly the same issue. I'm running Ubuntu 21.10. Restarting the service hasn't worked for me either, only logging out and logging in again. Randomly however, touchegg stops working.

Edit: Restarting the service seems to work. I did change the systemd service-file to run touchegg --debug --daemon rather than touchegg --daemon. Maybe that has something to do with it.

mazen-mardini avatar Jan 06 '22 16:01 mazen-mardini

It looks like the client (the touchegg command) is crashing, not the daemon.

If not installed already, could you install systemd-coredump and after a crash run sudo coredumpctl debug /usr/bin/touchegg and attach the output, please?

That should hopefully include a stack trace of the crash.

JoseExposito avatar Jan 07 '22 17:01 JoseExposito

So, it just happened again for the first time since posting this. I ran the command, and tried to direct it to a file and now when I press ^C it just prints Quit. But the output doesn't look useful to you anyway. Touchegg didn't crash, and I noticed that four-finger gestures are still working (though it seems to behave weirdly and I can't put a finger on exactly what is different) but three-finger gestures are not. And now when writing this, just now, it starts working again as I habitually switched to the terminal to check on the misbehaving process.

spikespaz avatar Jan 10 '22 12:01 spikespaz

@JoseExposito, I just installed Touchegg on my RPi4 today, and am running into a similar issue. I created the desktop file you shared in another post, and touchegg does appear to be running on startup because when I try to launch another instance it complains its already running, but it does not work (gestures result in no behavior) until I run "sudo systemctl restart touchegg" in a terminal window, then it behaves as expected.

Below is the output of my coredump (I hope that helps, I'm not familiar with coredump). The only thing I can make out is an abort signal...

Thank, B

PID: 1879 (touchegg) UID: 1000 (pi) GID: 1000 (pi) Signal: 6 (ABRT) Timestamp: Fri 2022-01-14 12:04:38 CST (1min 43s ago) Command Line: touchegg Executable: /usr/bin/touchegg Control Group: /user.slice/user-1000.slice/session-1.scope Unit: session-1.scope Slice: user-1000.slice Session: 1 Owner UID: 1000 (pi) Boot ID: b2584a84a5784595a7adeb23ce09b786 Machine ID: 86e24053a87844d8a883148b7c0d4f2e Hostname: raspberrypi Storage: /var/lib/systemd/coredump/core.touchegg.1000.b2584a84a5784595a7adeb23ce09b786.1879.1642183478000000.zst Message: Process 1879 (touchegg) of user 1000 dumped core.

            Stack trace of thread 1879:
            #0  0x00000000b5db58c0 __GI_raise (libc.so.6 + 0x318c0)
            #1  0x00000000b5d9e804 __GI_abort (libc.so.6 + 0x1a804)
            #2  0x00000000b5ff3f88 _ZN9__gnu_cxx27__verbose_terminate_handlerEv (libstdc++.so.6 + 0x7ff88)

GNU gdb (Raspbian 10.1-1.7) 10.1.90.20210103-git Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabihf". Type "show configuration" for configuration details. For bug reporting instructions, please see: https://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.

For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/touchegg... (No debugging symbols found in /usr/bin/touchegg) [New LWP 1879] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". Core was generated by `touchegg'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) Quit (gdb)

maranhaoBruno avatar Jan 14 '22 18:01 maranhaoBruno

@spikespaz

So, it just happened again for the first time since posting this. I ran the command, and tried to direct it to a file and now when I press ^C it just prints Quit

And it is my fault, because I forgot to mention than installing a debug version from source is required :man_facepalming: I'm so used to have the debug version installed to inspect crashes that I forgot the step, sorry :S

It can be done with the usual CMake steps, as described here, but using -DCMAKE_BUILD_TYPE=Debug instead of -DCMAKE_BUILD_TYPE=Release: https://github.com/JoseExposito/touchegg/blob/master/HACKING.md#compilation

Touchegg didn't crash, and I noticed that four-finger gestures are still working (though it seems to behave weirdly and I can't put a finger on exactly what is different) but three-finger gestures are not. And now when writing this, just now, it starts working again as I habitually switched to the terminal to check on the misbehaving process.

It could be than the client process is running but the systemd daemon crashed.

The daemon restarts automatically after 5 seconds after a crash. That could explain why it's back to normal after a while... But no the 3 fingers issue. Without the daemon running you shouldn't be able to perform any gesture.


@maranhaoBruno

This could be a different issue, but let's see...

I created the desktop file you shared in another post

How did you install Touchégg? Did you use the .deb package? (assuming you are using Raspberry Pi OS, which is based on Debian)

The installer should create the desktop file for you. If not, there is a problem in the package.

it does not work (gestures result in no behavior) until I run "sudo systemctl restart touchegg" in a terminal window, then it behaves as expected.

This could also be a problem with the package. Maybe the service is not enabled.

You can check it by running this command after rebooting:

$ systemctl status touchegg

● touchegg.service - Touchégg Daemon
     Loaded: loaded (/lib/systemd/system/touchegg.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2022-01-14 19:11:17 CET; 37min ago
       Docs: https://github.com/JoseExposito/touchegg/tree/master/installation#readme
   Main PID: 1962 (touchegg)
      Tasks: 4 (limit: 76757)
     Memory: 2.5M
     CGroup: /system.slice/touchegg.service
             └─1962 /usr/bin/touchegg --daemon

If Active: active (running) is not present, as a workaround you can manually enable the service:

$ sudo systemctl enable touchegg.service

But the installer should do it for you.

JoseExposito avatar Jan 14 '22 18:01 JoseExposito

@JoseExposito

How did you install Touchégg? Did you use the .deb package? (assuming you are using Raspberry Pi OS, which is based on Debian)

I tried to install from the deb package, but it wouldn't work (I apologize, I don't recall what the issue was), so I downloaded the code and compiled it; that worked flawlessly. One a side note, I was unable to install Touché as it requires libgtk-4-dev and this is still experimental in Debian, and I figured it was just easier to manually edit the XML configuration file than to work around this.

This could also be a problem with the package. Maybe the service is not enabled.

You can check it by running this command after rebooting:

When I initially checked the status of touchegg it was indeed inactive. I ran the enable command and rebooted and now it is working. Thanks!

maranhaoBruno avatar Jan 15 '22 11:01 maranhaoBruno

I tried to install from the deb package, but it wouldn't work (I apologize, I don't recall what the issue was), so I downloaded the code and compiled it

Ok, that's why the service was not enabled, the package does it for you, but when installing from source it needs to be performed manually.

One a side note, I was unable to install Touché as it requires libgtk-4-dev and this is still experimental in Debian

You can install it from FlatHub and avoid the dependencies issue:

https://flatpak.org/setup/Raspberry%20Pi%20OS/

https://flathub.org/apps/details/com.github.joseexposito.touche

JoseExposito avatar Jan 15 '22 11:01 JoseExposito

same happens on debian based distro installed via ppa (kubuntu 22.04) any way out? For me it only stops working after log out login.

niksingh710 avatar May 04 '22 05:05 niksingh710

@spikespaz The solution is to set psmouse.synaptics_intertouch=1 in the kernel boot line, in my case it was in the line GRUB_CMDLINE_LINUX_DEFAULT of /etc/default/grub

For the reason see https://gitlab.freedesktop.org/libinput/libinput/-/issues/624#note_971747

cheerio-pixel avatar Oct 14 '22 13:10 cheerio-pixel