I’m running duplicati 2.0.6.3_beta_2021-06-17 on Open SUSE Tumbleweed using GNOME 42.0. After duplicati runs gnome starts to “sputter” - my mouse movements become unsmooth and jerky like the system is freezing and unfreezing in rapid succession. This is happening even if duplicati isn’t actively performing any backups or maintenance.
Logging out of gnome and back in again seems to resolve the problem but has the unfortunate affect of closing every application I have open. Since I perform backups on a daily basis I end up having to log in and out of gnome once per day.
If I stop all backups from happening then this problem doesn’t occur, and this problem wasn’t occurring prior to me installing duplicati. It seems like something duplicati is doing is impacting gnome. I had a look at system monitor when it was hanging and I didn’t see any particular process chewing up memory, cpu or creating lots of io.
Has anyone else experienced this with gnome 42 or have any idea how to address this? Its super annoying and I don’t want to have to switch to another backup solution or re-install my OS just to not use gnome 42.
You should easily be able to use Deja Dup I think since you’re using Gnome and I think rpm. I used that for years. Its really stable but just slow. That is its only major con over Duplicati. Its meant to be simple so there’s a lot less code bugs.
I’m purposely avoiding talking about Duplicati and Linux sorry. I zipped and threw away the key
The two statements seem contradictory, or do you mean backup starts it then it persists after backup?
I suppose you could look at the virtual memory situation. Paging can sometimes cause annoying gaps.
I’d expect memory to resolve unless there’s a chronic lack. Tools to run include sar -B, top, and vmstat.
There are options to reduce Duplicati CPU and I/O priority, but those would matter when it’s doing work which is why I’m trying to better understand when this happens. You can also try moving browser work elsewhere, e.g. change Settings to let you to come in from some other system. Both browser and Tray Icon do some polling to stay up to date. You can also stop the browser polling by closing Duplicati’s tab. Stopping TrayIcon polling can be done by running duplicati-server, which (I think) has no need to poll…
While a desktop environment flameware would be off topic here, I’d say that I recently tried Kubuntu after years of Ubuntu 20.04 LTS (that is, switching from Gnome to KDE) and I don’t really miss anything It’s still Ubuntu under the KDE hood, but without Gnome shell (that’s a major plus for me), and it may be the same for Suse and Plasma.
The two statements seem contradictory, or do you mean backup starts it then it persists after backup?
The backup starts and finishes, and you can even kill the duplicati process and mono and the problem continues. So duplicati is causing some other system process to get into a bad state. I am guessing it may be gnome-shell because I see it consuming 10% CPU (Which is more than any other proces) and I can log out and log back into gnome and the issue stops.
I suppose you could look at the virtual memory situation. Paging can sometimes cause annoying gaps. I’d expect memory to resolve unless there’s a chronic lack. Tools to run include sar -B, top, and vmstat.
procs -----------memory---------- —swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 3187968 655260 24288 42148676 1 4 332 711 14 24 5 6 88 0 0
I suppose you could try to narrow it down by running Duplicati different ways. Looking at something like output from ps -ef, is Duplicati running as Duplicati.Server.exe or Duplicati.GUI.TrayIcon.exe which is perhaps interacting more directly with the GNOME GUI and should give you an icon to watch and use?
You could also test a completely command line backup (not at the same time as a scheduled GUI one). Export As Command-line should give you a line you can paste into a shell. Does it bother gnome-shell?
To find out if browser activity is required, you could set Settings to let you come in by IP from off-system.
You could also try a scheduled GUI backup without having any browser tab open for Duplicati to write to.
You could also test some other operations besides backups, and see whether anything else sets this off. Perhaps you did already? The original post talked about “maintenance” but it wasn’t clear what that was.
Basically I have no idea what gnome-shell dislikes, but narrowing it down might help if you need to ask.
You could also test a completely command line backup (not at the same time as a scheduled GUI one). Export As Command-line should give you a line you can paste into a shell. Does it bother gnome-shell?
Tried running all my jobs via the CLI and the issue doesn’t happen.
Since I see TrayIcon running as you, you should have a visible TrayIcon somewhere around.
It should change its color sometimes, and provide a limited menu. If not, something’s broken.
If all seems well (except for gnome-shell), one can get rid of TrayIcon and run just the Server.
Your Duplicati looks like a non-systemd launch, maybe from the /usr/bin/duplicati script. /usr/bin/duplicati-server is just the server. You can start from a shell and Ctrl-C to stop.
Stopping that way is best done when a backup is not running. TrayIcon Quit won’t Quit early.
This suggests (not surprisingly) that it’s not the backup, but interaction with desktop somehow.
There were some other possible tests, for example Verify files is a small test that gets the
TrayIcon green briefly. If that causes the problem, TrayIcon becomes even more of a suspect.
The other thing that might interact with desktop (or is it strictly the window?) might be browser.
There were some earlier thoughts about how to try to get browser out of the local GUI for tests.
I have switched from using the Tray Icon to using the Server which runs as a linux systemctl unit/service. I can no longer see the backup status in my system tray which stinks (as its hard to keep an eye on failing backups) - but will monitor it for the next day or two and see if that helps. Will report back findings soon.
People who run the systemd (or Windows) service can run the tray icon with –no-hosted-server.
This has trouble if there’s a GUI password, and in your case, it might also make GNOME glitch.
In the latter respect, it would be another interesting test to try to isolate the issue even further…
I recently upgraded to PopOS 22.04 (Gnome 42 based) and I noticed similar behavior (not sure if it is exactly the same). For now - what I am isolating it to is sleep (suspend).
If the computer is suspended and woken up - at some point (usually not right away) starts moving very slowly - becomes unresponsive until it completely crashes. It often crashes to completely black screen. The errors are I/O related can’t read from the disk. However - I checked it multiple times with fsck -f. Each time it crashes the FS becomes corrupted (and fsck fixes it) but then it crashes again. SMART says the disk is okay (even it is older - 4+ years up time - SSD)
However - if I never put the computer to sleep and just shut it down or leave it on all the time - it keeps going - can be a week without any issues vs several crashes per day if it was suspended before.
This is an older machine - Dell XPS x2 - Intel sandy bridge Sandy Bridge - Wikipedia - i7 gen 2 Intel Core - Wikipedia - laptop - 8Gig RAM Samsung SSD.
At some point I read that some kernel are not quite happy with the suspend mode.
Even if what I am experience is not exactly what you are observing - it is worth it trying - if nothing else it would confirm if the 2 issues are related or not.
