appimagelauncherd.service makes the system to lag for a second every 30 seconds

[jjchico]

Describe the bug

My had a short lag (about 1 second) every 30 seconds exactly. Only happened with my user account and not other accounts. It was driving me crazy. After de-activating the user services one by one I discovered that appimagelauncherd.service was the culprit.

Expected behavior

Processes not stopping every 30 seconds when the system is under low load/idle.

To Reproduce

Steps to reproduce the behavior:

1. Install AppImageLauncher from the releases page (mine is 2.1.0).

2. Run AppImageLauncherSettings. Under the "appimagelauncherd" tab, make sure the "Auto start auto-integration daemon" is checked and accept.

3. Close all windows.

4. Open a terminal and make the system to do something continuously that you can easily observe like echoing "X", one full line every second:

   $ while true; do echo -n 'X'; sleep 0.0125; done

5. You will see that X's stop printing for a short time (about half a second) every 30 seconds. Actually, it also stops for an even shorter time (about 1/10 seconds) 10 seconds after the 1/2 second pause. That is, a 1/2 second pause every 30 seconds and another 1/10 pause every 30 seconds, with a time displacement of 10 seconds one from the other.

To time it you can open another terminal an run this:

$ while true; do time=$(date +%s); echo $(($time - ${oldtime:-0})); oldtime=$time; read; done

Press enter on this terminal everytime you see the X's stopping.

Workaround

Momentarily, stop the user's appimagelauncherd service:

`$ systemctl --user stop appimagelauncherd.service`

Permanently, uncheck the "Auto start auto-integration daemon" option in AppImageLauncherSettings.

System, software and AppImage information

AppImageLauncher 2.1.0 installed from the official release at GitHub. Ubuntu 18.04.4 LTS running in both Intel and AMD 64-bit platforms.

$ cat /etc/issue
Ubuntu 18.04.4 LTS \n \l

$ uname -a
Linux valhalla 4.15.0-76-generic #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

$ apt show appimagelauncher 
Package: appimagelauncher
Version: 2.1.0-travis897~d1be7e7+bionic
Status: install ok installed
Priority: optional
Section: devel
Maintainer: TheAssassin

List of AppImages you tried:

• FreeCAD, OpenSCAD.

[jjchico]

I am not a CPP programmer (or any other kind of programmer by the way :) but I see in the source code that what is called every 30s is "FileSystemWatcher::updateWatchedDirectories" in fswatcher/filesystemwatcher.cpp. At some point in this method there is a mutex lock. Should not be a mutex unlock at the end of the method?

Just guessing in case it is useful to true programmers.

[TheAssassin]

Should not be a mutex unlock at the end of the method?

The mutex is unlocked due to making use of RAII. The locker locks during construction and unlocks when deconstructed. The deconstruction occurs when the scope is left, which happens in line 341.

Given the timing it looks indeed like that directory update is causing your lag. I wonder why though. I can only guess what the issue might be on your system. Perhaps the update requires spinning up HDDs or something?

[jjchico]

You are right about the mutex. I tested two systems with the same behaviour. One of them is a Ryzen 5 with only one SSD drive and in the other one I have spinning down disabled for all hard drives, so I would discard HD configuration issues.

I've also tried: reinstalling, installing the continuous build version, removing the config file, changing the Applications folder, etc. with no luck.

Maybe is a problem of my systems or the way I configure them. Let's see if other user have the same problem.

Thanks for your time and effort. Your App is really useful.

[TheAssassin]

I've never noticed anything like that to be honest. I have very low end to very capable systems and have never seen anything like what you describe.

I can only say that the current system with its polling every thirty seconds is annoying, and on my way home I figured out how to realize a faster (as in, lower reaction time) and cheaper (as in, way less work) update system. I hope I'll get to implementing that soon. It'll basically use inotify as much as possible for everything, and therefore doesn't have to actively make lookups into the filesystem unless there is an actual change that requires action. Of course there'll be some traffic from inotify to the daemon, but it can filter that for relevant events easily. That should overall reduce the amount of computations made, minimize the performance impact and also reduce power consumption (as right now spinning down HDDs is effectively prevented by the daemon, which is really bad).

[jjchico]

I continued to do some testing but I am really puzzled. My app folder is in /opt/Applications. What I see is:

• If I install AppImageLauncher from the beginning leaving the default $HOME/Applications folder It seems to work right.
• If I later change to /opt/Applications, the lag stats, even if /opt/Applications is empty. Applications are unregistered correctly.
• If I put my application in /opt/Applications everything works fine, but the lag continues.
• If I change it back to $HOME/Applications it works fine, but the lag does not dissapears.
• It seems than only X-Window system is laggy (I use X.org, no Wayland). If I change to a console terminal (without closing the X-Windows system session) and I run my "XXXXX..." test, I see no lag as I see in the X-terminal and in any other X windows by the way.
• During the pauses, neither appimagelauncherd or appimagelauncherfs daemons log any message.

My conclusion is that something done by AppImageLauncher is interfering with the X-Window system. Maybe the registering-unregistering of desktop or mime files.

I do not think it is a performance problem: a modern 8-cores computer should be able to run smoothly even if a process is fully busy. Anyway, removing the polling as you propose seems the right way to go.

People reading this may test using a non-default Applications folder and try to reproduce it.

I do not want to consume your time with my particular problem. I'll check new version and report any changes.

[colinl]

@jjhico are you using Gnome? If so are you seeing a memory leak in gnome-shell (several MB/min on average)? It sometimes takes a little while to get going though.

[colinl]

I am seeing the display glitches too, when the daemon is running with a non-standard destination folder. I suspect this is related to a gnome-shell issue which causes it to leak memory when appimagelauncher daemon is running, but again only if the destination location has been moved away from the default. I don't think gnome-shell should leak memory whatever appimagelauncher does but it may be something like appimagelauncher doing something unusual and triggering a bug in gnome-shell. https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1862910

[TheAssassin]

Possibly related to #445.