The symptoms are very much like reported here. However, the system specs are different as well as I cannot see having any non-excluded links pointing to “/”. So, the reason must be a different one.
Specs:
Operating System: Fedora 40 (latest updates as per this writing)
Background:
Since the client crashed in the past in a similar fashion (that is, consumed all memory until the OS became unresponsive), I wrote a script wrapper around the client to kill it off if it consumed 50% of my available memory (in my case 8G) and restarts it 10 seconds later.
Current Situation:
I reset the files of my Nextcloud user (moved the Nextcloud user directory on my server and removed all references to these files from the database).
Just to be sure, I also repaired the Nextcloud instance to not run afoul when starting to synchronize files again.
After that, I set up the client again and the synchronization appeared to run well. I saw the files starting to populate on the server again and so I waited until all was done.
However, close to the finish line, it must have crashed as the wrapper script started killing off the Nextcloud client. Since then, it starts up the client, but crashes as soon as it resumes synchronization.
The client logs do not appear to hold any information as to what happened. So, I am a bit lost as to where to look to get to the bottom of this.
Is there anywhere else I can check to see what is going on? Why it suddenly starts chewing over a specific file for instance?
Are there any file types (e.g. hardlinks), which can bring the client down?
I am happy to provide more information and/or logs, if needed.
A dirty workaround. If the application has a memory leak, it should be reported to the developers and they should then work on it and solve it, so it is fixed. Such workarounds, I don’t know if you can still close it gracefully, or if it stops everything even when the client is about to write something.
full ack - killing the client will reliably brake it over time. The client uses local DB to keep track of files state. if it crashes this DB might become corrupted and you never recover from the issue.
I would recommend you
remove the DB
(.sync_{random string}.db.sync_{random string}.db-shm.sync_{random string}.db-wal in your client sync folder)
let the client complete the full sync (takes long time) and
Thanks! Though what you suggested was my starting point. Client-sided I usually remove everything Nextcloud-related (minus the sync-client application). In this case I also kept the config and logs, but all sync DBs were removed. This is not so much due to potential corruption, but to make sure that the sync direction is client → server and not the other way around.
As stated: Synchronization started well, but then short before it was finished (it indicated some 100+ files left to copy), it just crashed and my wrapper script then terminated (signal 15) the application after a while when it reached the threshold.
Adding a +1 to this issue. If I pause syncing immediately after opening the nextcloud client, the client will not crash and a memory leak does not occur.
Operating System: Fedora 40 (latest as of 2024-06-25)
Nextcloud Client: 3.13.0
Nextcloud Server: 29.0.2 selfhosted on a proxmox debian LXC running LAMP stack.
This issue was not present before my fedora update on 2024-06-25. The issue is currently not present on my Ubuntu 24.04 laptop (client v3.11.0) and Windows 11 VM (client v3.13.0).
Downgrading my client to 3.12.1 on my fedora laptop resolves the issue. The issue returns if I upgrade back to 3.13.0.
Thanks @matthew ! That I should have tested as well, and did now and I can say that, like your experience, v3.12.1 is generally stable.
However, even that version goes haywire if you start entirely unrelated applications, e.g. Steam client, for which case I have written the wrapper script. Once Steam is started, the Nextcloud client can be started again and it behaves normal going forward. However, it can as well be reproduced 100% by simply quitting Steam and restarting it.
I honestly do not know what is going on at the start of Steam, but it is likely the Nextcloud client is writing to memory it shouldn’t and then when the Steam client starts, it itself writes to that address making the Nextcloud client unstable. While it is absolutely possible that the Steam client is doing something wrong, since only the Nextcloud client is affected and only during Steam startup, I tend to believe that it is likely caused by the Nextloud client, which with v3.13.0 expanded that pre-existing memory leak.
With that information I can see about writing a bug report in the coming days, if not already done by someone else. So far I downgraded to v3.12.1 and excluded v3.13.0 from being upgraded to. A temporary fix I can live with.