nextcloud
[Bug]: Memory Leak on Linux with 3.13 client version
⚠️ Before submitting, please verify the following: ⚠️
- [X] This is a bug, not a question or a configuration issue.
- [X] This issue is not already reported on Github (I've searched it).
- [X] Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
- [X] I agree to follow Nextcloud's Code of Conduct
Bug description
Memory usage of the nextcloud-client application slowly creeps up in RAM usage until the system goes oom; Had my PC running and going for a walk, came back to it using 59GB of RAM (i have 64GB) and the system becoming completely unresponsive.
Steps to reproduce
- Open and use the newest Nextcloud-Client for Linux (either from the arch extra repo or the git version from AUR / Chaotic-AUR
- Observe it using as much RAM as it can get.
Expected behavior
It not using all the RAM
Which files are affected by this bug
No File but the basic application itself
Operating system
Linux
Which version of the operating system you are running.
Garuda Linux - 6.8.7-zen1-2-zen Kernel
Package
Distro package manager
Nextcloud Server version
28.0.4
Nextcloud Desktop Client version
3.13.0.r268.gaa175036e9-1 // 3.13
Is this bug present after an update or on a fresh install?
Updated from a minor version (ex. 3.4.2 to 3.4.4)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
Are you using an external user-backend?
- [X] Default internal user-backend
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other
Nextcloud Server logs
No response
Additional info
Downgrading to 3.12 stops the memory leak
Same issue on Arch Linux (6.6.29-1-lts). It seems to have been introduced somewhere in 3.13, as 3.12.3-2 does not exhibit the issue. If I have the time I will try to bisect it to find the offending commit.
Same issue with the 3.13 AppImage on Ubuntu 20.04.6 LTS. I have an old laptop with 8GB memory so hardly had the chance to stop the client after auto startup. I put 3.12 back in place and everything works fine again.
Same on Manjaro. At some point my computer was struggling then I looked and Nextcloud was using all the ram + all the swap. So I downgraded to 3.12 and it's working fine.
I noticed this just after upgrading to Manjaro 24 with Plasma 6 and stuff. Not sure If Nextcloud 3.13 was updated at same time. It might be a bit hard to nail down the change causing this because there was a lot of change in one update.
Same issue on Arch Linux with NextCloud 29 server and client 3.13.0 20GB RAM used in less than 20min and client killed by OOM. Repeated 3 times.
It happens on NixOS 24.05 as well (and unstable since they're the same). It works if I go back to the NixOS 23.11 version (3.12.3).
I believe that uses a version of the snap package
When I look at https://download.nextcloud.com/desktop/releases/Linux/ I see that the the date of 3.13 is before 3.12.4 which is 2 versions older. I would expect the last version to have the last date. Maybe this 3.13 is a pre-release and was not meant to be out there ? BlueMail voor Android downloaden
Op 9 jun 2024 23:19, om 23:19, RandomLegend @.***> schreef:
Still not closed?
-- Reply to this email directly or view it on GitHub: https://github.com/nextcloud/desktop/issues/6711#issuecomment-2156794938 You are receiving this because you commented.
Message ID: @.***>
I'm experiencing the same issue with AppImage client 3.13.0 against server 28.0.5. I'm able to prevent Nextcloud from crashing my system with the following command:
systemd-run --scope -p MemoryMax=8G -p CPUQuota="90%" --user ~/.local/bin/nextcloud.AppImage --background &
This only makes it easier to test without having to hold the power button of my laptop, it doesn't fix the issue.
After switching back to Nextcloud Appimage 3.12.5 sync started working again, so definitely a bug in the latest version.
I think the people with the Windows Desktop version have the same issue : https://github.com/nextcloud/desktop/issues/6749
Just tried the AppImage 3.13.1 on my Ubuntu and saw memory fill up within some seconds until my desktop froze. Had to pull the plug and reboot and delete the AppImage asap and reboot again to get back up and running. Went back to AppImage version 3.12.5.
Tried AppImage 3.13.2 on Ubuntu and had to kill it again and am back to 3.12.5 like before.
I see something strange on the page with releases. ( https://download.nextcloud.com/desktop/releases/Linux/ ) 3.13.0 was released on 2024-04-24 09:23 Since then we also have releases of the preceding 3.12.x : 3.12.4, 3.12.5, 3.12.6 and 3.12.7 which all do not have the issue. There are also releases 3.13.1 and 3.13.2 which all have the issue like 3.13.0 Why are they continuing with 3.12 ? Do I need to do something to get 3.13.x working ? Am I missing something ? I am running 3.12.7 now.
For the manjaro and possibly arch folks:
I installed the package downgrade and then did
sudo DOWNGRADE_FROM_ALA=1 downgrade nextcloud-client
choosing nextcloud-client-2:3.12.3-2 which temporarily fixed it for me.
Issue solved ? I always use the AppImage version from https://download.nextcloud.com/desktop/releases/Linux/ and today I found there is a new one 3.13.3 dated 23-08-2024 and this one does not seem to have the issue. My memory consumption with earlier releases went up like a rocket but now it is stable already for about 20 minutes.
Not fixed for me - 3.13.3 (on Manjaro KDE) had been indeed working for some time without issues but two days ago started again getting random freezes on my desktop, figured out it might be the app again - after restart this morning I've found the taskbar icon went back to "Sync is running", one processor core at 100% and RAM use growing indefinitely. Idk what happened, didn't do anything different, the app somehow has unfixed itself? Going back to 3.12.
I got the same problem on Tuxedo OS (Kubuntu) with Nextcloud client version 3.14.0. The client crashes at some point, stops syncing and uses up the RAM. I use the Flatpak version. going back to 3.12.3 fixed the issue.
Seriously this bug should be given more priority. It is not a small bug it completely crash the whole system and make the computer unusable. This thing should be reverted back to a working state asap and never reach the end user.
It would be useful to have some feedback as to how to get this bug approved or how to gather more info. I think we all end up staying with an old version just to have the client working, but at some point that's gonna come back to bite us.
I had a memory leak like this when i had a recursive symlink on my system. I had Documents folder pointing to itself inside it. You can check it by running nextcloud client with strace
I got rid of all the recursive symlinks I found in the folders I'm syncing and so far the new versions seem to be working fine. Wine and steam particularly do create a lot of those.
This snippet from Stack Overflow should help find them:
find -L . >/dev/null
I got rid of all the recursive symlinks I found in the folders I'm syncing and so far the new versions seem to be working fine. Wine and steam particularly do create a lot of those.
This snippet from Stack Overflow should help find them:
find -L . >/dev/null
I believe what changed is that now the client syncs the contents of symlinks the same as folders, previously you had to do --bind mounts.
I got rid of all the recursive symlinks I found in the folders I'm syncing and so far the new versions seem to be working fine. Wine and steam particularly do create a lot of those.
This snippet from Stack Overflow should help find them:
find -L . >/dev/null
Many thanks for this tip I went back to an earlier version before because the issue returned. With this tip I found 1 single loop, removed it and I am running 3.14.2 now without the memory issue. I hope this is a temporary workaround for this issue and that developers will find a solution for this. The solution must be there because the issue was not there before.
I got rid of all the recursive symlinks I found in the folders I'm syncing and so far the new versions seem to be working fine. Wine and steam particularly do create a lot of those.
This snippet from Stack Overflow should help find them:
find -L . >/dev/null
This worked for me as well. I discovered a pair of recursive symlinks that I had created myself some time ago. Additionally, while .steam and .wine may contain recursive symlinks, as long as these folders are in the Nextcloud client’s ignore list, it shouldn't cause any issues. If these folders are excluded from your sync, you can search for recursive symlinks while excluding these folders using the following command:
$ find -L . \( -path ./.wine -o -path ./.steam \) -prune >/dev/null
Ok, but we still do treat this a bug that needs to be fixed, right? I'm not able to remove all recursive symlinks due to how I keep my data organized.
This issue is still present in Nextcloud 3.15.3! I downgraded to 3.12.3 and it fixed my issue immediately, first sync worked correctly and no memory leak eating my entire RAM. I think this should be taken more seriously as mentioned above.
I have been affected by this issue, it happens more frequently during sync although at some times I have experienced it while my system is idle.
I am running Fedora 41 with Plasma desktop, and I have seen the issue with the AppImage downloaded from the official website, with the Flatpak from flathub and with the rpm package from the Fedora repositories.
Still present today, to downgrade for Arch users:
$ sudo pacman -U https://archive.archlinux.org/packages/n/nextcloud-client/nextcloud-client-2%3A3.12.3-2-x86_64.pkg.tar.zst
and
IgnorePkg = nextcloud-client
in /etc/pacman.conf until it is fixed
Still relevant, thanks fermino, seems find -L . >/dev/null (and removing symlinks) do the trick
Still relevant, thanks fermino, seems
find -L . >/dev/null(and removing symlinks) do the trick
for me this comand (and also $ find -L . ( -path ./.wine -o -path ./.steam ) -prune >/dev/null) gives me no results. Still got the issue though.