[Bug]: Desktop Client freezes in a 100% CPU load loop after server upgrade to 25 #5094
Comments
|
Looks like the same issue: #4106 |
|
@RainerKlute would you be able to share your logs ? |
|
Hello, The addition of "'bulkupload.enabled' => false," in config.php solved my problem.
like this: #5031 Server : Client : ######################### After reading this message: #4106 (comment) I disabled the automatic upload speed limitation option, and the client not freeze |
|
I was able to sync a lot of files these days with desktop client 3.6.1 on openSUSE Tumbleweed 20221003 and Nextcloud 25.0.1 RC1. However, after having synced a lot of files it's now stuck at 100%. the nextcloud.log has this message: Basically: when I start the desktop client again, first I see the above message and then suddenly it's 100% CPU on the client side. Let me know where I should look if there's a way to provide more information. |
|
I've just tried to make the server return a clean 400 Bad Request but the client still stucks at 100% CPU, so perhaps the error handling there has some issue or infinite loop of sorts. The server side error seems to be about some problem in the multi part request. Ah, and I just noticed that today I enabled the upload speed limitation and that it was reported to cause trouble also in the original report. @mgallien |
|
I've restarted the client, paused the sync, then removed the upload and download speed limit, then resumed sync: no more issues maybe there's something odd with the combination of bulk upload and upload speed limit |
|
The server is failing when trying to seek the stream backward. Two possibilities:
|
|
from my experience, doing an fseek backwards is often not a good idea as it can break on streams (not files) |
|
Same thing here. Using Mac OS client. |
|
Same, CPU & RAM usage are really high and I just get EDIT - I'm using Windows Desktop Client |
|
I'm also affected after upgrading to Nextcloud 25. Can confirm that disabling "upload limiting" in the desktop client makes this bug go away (but it then hoses my upload bandwidth to the point of making downloading impossible whenever I have a large upload). NextCloud 25.0.1 |
|
Any updates to this? Even in v3.6.2 the errors occur. |
|
I can reproduce this bug and can confirm that removing the speed limit solves it. It is the combo of bulk upload + speed limits that cause this issue but it "just" looks like a bug in the client and server side the files had synchronised properly, still the client hangs with high cpu use. |
solves the issue for me ! |
|
I can confirm this issue and the solution of setting the Bandwidths to "No limit" on Debian Bullseye. |
|
Hello! |
same here - solved the issue for me |
|
can confirm the issue on ubuntu 20.04 with client 3.5.4 (x86_64), when bw-limits are in place. PS: because this box is unchecked in the OP: the NC25-Server uses LDAP as it's userbase. |
|
I can confirm the issues on Ubuntu Mate 22.04 with the default client from the sources as well as the most recent version (3.6.2) from Disabling the bandwidth limits made the client sync again. At first, I couldn't access the settings in the GUI, because it would freeze right after (re-)starting the client. So, to get to the settings, I edited the config file |
That's how i solved it, too. |
|
Hello, |
|
@rstockm |
|
@PhilippSchlesinger I don't know why @rstockm is running such an old client but this issue is still happening in 3.13.0. The fix mentioned as being in 3.9.0 never did work. Many people have confirmed the issue on versions since then. |
I can confirm on Linux the 3.13.0 version is buggy and causes my computer to hang with 100% cpu load. It works fine with the 3.9.0 appimage |
I have tried 3.3.4, 3.9, and 3.13.2 on Mac. They all have this showstopper bug. As near as I can determine, is no working NextCloud client for Mac, and nobody wants to admit it. Is this project abandoned? Why are issues going months without even being acknowledged? |
|
@kupietools You're being a bit rediculious, obviously with an ongoing string of releases this project is not abandoned. Some issues are just a bit miss-managed. For whatever reason nobody wants to own up to there being a bug here and just re-open the issue. Also if you actually read the comments before you you'll notice it is not a Mac issue and there is a work around. Meanwhile you can use any client version you like just fine but you have to get your Nextcloud cloud instance admin (maybe that's yourself?) to add |
Sadly that leads to a huge performance loss. I'm often syncing a bunch of tiny data around (target folder for scientific simulations with a lot of small results files) and even when synced directly over GigE in the same network, the workaround made syncing lots of small files very tedious. How such a critical bug can remain unaddressed for now almost 2 years since the first bug report is beyond me. If it is very difficult to fix, and needs time, so be it. But we did not even get a "yeah, this is a bug, we know about it and work on it" message so far. Just some random closing of the issue report while the actual issue persisted just the same. |
|
Yes, the workaround is very much suboptimal. |
|
Yes, the work around is very much less than sub-optimal. But for most folks slow is better than 100% CPU usage and no functionality. I don't know how this hasn't hit any developers such that they would be motivated to actually chase it down, and I don't know enough about debugging the desktop app to track down the problem myself. |
|
The workaround was useful while it was needed. I reverted my Nextcloud instance back to |
Same. I'd help if I could, but I really lack the skills for that, sadly. |
|
@RainerKlute Clearly not everybody is affected (or developers would have given it more attention long ago) but also whatever the trigger is many people are still affected. I'm glad you are not, but that just suggests whatever the trigger scenario is is not being hit by you, not that the bug is fixed. Also what clients are you using? Besides the server-side work around the client can also be compiled without bulk upload support, and several distros do this. For example the Arch Linux has the feature patched out so that nobody on Arch Linux is likely to ever see this issue. I've thought of re-enabling it to put pressure back on devs to find this problem, but I also don't want to deal with a bunch of bug reports and hassle for all Arch Linux users that would be negatively affected. |
|
Oh, now that explains why I only encountered it on Windows, not on Arch... |
|
The nextcloud desktop client app on Arch Linux has this monkey patch that changes the code that detects never capabilities to always report false for bulk upload. This makes it slower than necessary but keeps the client from freezing up. I've tried disabling it several times and not only my own systems but other reports of problems start flooding in. |
I am using the Nextcloud client that comes with openSUSE Tumbleweed. Don’t know whether bulk upload is inhibited there or how to find out. The server is also running openSUSE Tumbleweed. |
|
I just reviewed the sources for OpenSUSE Tumbleweed's Nextcloud server and desktop packages and it does not look like they have patched out bulk upload support on either side. Thanks an interesting data point but doesn't isolate what the unique factors are, and we know multiple host platforms and all of Windows/macOS/Linux clients are affected in some cases. Do you by chance use any of the rate limiting features on the client? Those seem to be another way people work around triggering this bug. |
|
Thanks for responding, all. Unfortunately my server is a Hetzner Storage Share, they've already passed the buck and told me that while I can continue to pay them money, this is not their problem and they'll do nothing to help, and it's entirely up to me to convince the NextCloud devs to address the problem. However, I'll ask them if setting I did discover that the OwnCloud client works and appears not to freeze. However, while NextCloud told me (between freezes) to expect about a four-day wait to upload 400GB of files, OwnCloud wavered between 3-9 months for the same files, so this doesn't seem like a workable solution. I'd rather not wait the better part of a year for my first sync to finish.
I've tried rate limiting both auto and off for download, for both NextCloud and OwnCloud clients. I am reluctant to turn rate limiting off for upload as this can easily slow up the machine's entire connection due to the back-and-forth packets needed just for downloading, but I'll give it a shot. I did try turning the upload limiting off in OwnCloud to see if it made a difference in the speed, and it didn't seem to. UPDATE: I let it run with the upload and download both not rate-limited, and it froze again inside of a few hours. |
|
Obviously, we're discussing something here that is different to the original bug reported, which is not the most effective thing to do. My installation has been affected by the problem, and to cure that problem as originally reported it has been - and is - sufficient to switch Download and Upload bandwidth limit to "no limit" at the client. Though I'm not a fan of the way it was fixed, certainly this problem is fixed. As you are experiencing problems with clients freezing with 100% CPU load, obviously it is a different problem and deserves a different report. |
I never used the rate limiting, the only thing that worked ever since it first happened has been to disable bulk upload on the server. It's definitely the same issue - bulk upload being enabled results in clients freezing while using 100% CPU. That's the same as the original. |
This won't fix any bugs in any way, but if you just want to run an initial sync of your data this is what worked for me with a Hetzner Share:
|
Thanks for the suggestion! I decided to pay for Hetzner's NextCloud hosting because I did look at just paying for cloud storage and using WebDAV to sync, and it wasn't going to work for my purposes. It costs 50% more than their bare-bones cloud storage, I would have just gone for that if that was going to work for me. |
|
@unterkomplex So, just to follow up, I did end up trying rclone, just to see if maybe, once one sync was done, maybe the owncloud client's slowness wouldn't be an issue in keeping everything up to date. The results: 1.) Through several days of crashes and manual restarts, the NextCloud client got me about 75% synced. That had taken a few days, including a lot of downtime when I didn't realize it was crashed. Last I looked, Rclone estimated it would take over a month to complete the final 25%. 2.) I tried anyway and gave it about a week. Twice in that time, I looked and the command-line rclone client had aborted due to I/O errors. (BTW I'll spare you an exhaustive description of my network, but any configuration or connectivity problems on my computer or network would cause way more things going wrong than just one single app reporting errors and nothing else.) This isn't usable. I just canceled my Hetzner Storage Share account. I won't using NextCloud, since in several weeks of trying it hasn't worked for me at all and I haven't been able to find any sign at all that the devs have any interest in fixing the bugs. Thank you so much to the several people here who did reply here—I really appreciate your efforts to be helpful! |
|
@kupietools have you tried using an older nc client? The bug ceased to affect my server and computer whenever i was using an old client. |
|
@kupietools if you want to sync data and do not really care about a fast response time and you just want to keep the data up to date after the initial sync, then you should try looking at https://github.com/syncthing/syncthing. I am currently using that as a backup solution for my rasberry pies to my storage server. It might be a bit slow to start the sync but should handle your crashes fine. It will just wait until the connection is back. It is also very lightweight. |
We are migrating from pCloud to hetzner nextcloud because the pCloud client also sucks and filled our 100MBit uplink for 3 weeks, continuously resyncing the same files and impeding our other applications. We already have the full cloud (128G, 239255 files) mirrored here on the linux server. There still is a kind of initial sync needed because nextcloudcmd needs to build the database which is used to determine whether files missing on one side should be resynced or deleted, even if it doesn't need to transfer any files because they're already there. The first runs aborted because they ran into the ulimit -n of 1024 files. In conclusion, the cli²ent has several issues:
|
and others
Bug description
After upgrading the server to NC 25 stable (25.0.0.18, to be exact), the desktop client (3.6.1 on openSUSE Tumbleweed) does no longer sync from the client to the server. Instead, the client totally freezes, while using 100% CPU load.
It turned out that the bulk upload feature is in error. As a workaround, I turned off bulk upload in the server’s config.php file by adding the following line:
'bulkupload.enabled' => false,Steps to reproduce
See the description above.
Expected behavior
The client should never freeze, even if the server is behaving incorrectly. Ideally, the client should support bulk upload. As the very minimum – for example, if the origin error is on the server side –, it should fall back to normal upload.
Which files are affected by this bug
–
Operating system
Linux
Which version of the operating system you are running.
openSUSE Tumbleweed
Package
Distro package manager
Nextcloud Server version
25.0.0.18
Nextcloud Desktop Client version
3.6.1
Is this bug present after an update or on a fresh install?
Fresh desktop client install
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
Are you using an external user-backend?
Nextcloud Server logs
{ "app" : "webdav", "exception" : { "Code" : 500, "CustomMessage" : "Unknown error while seeking content", "Exception" : "Sabre\\DAV\\Exception", "File" : "/data/nextcloud/apps/dav/lib/BulkUpload/MultipartRequestParser.php", "Line" : 111, "Message" : "Unknown error while seeking content", "Trace" : [ { "class" : "OCA\\DAV\\BulkUpload\\MultipartRequestParser", "file" : "/data/nextcloud/apps/dav/lib/BulkUpload/MultipartRequestParser.php", "function" : "isAt", "line" : 129, "type" : "->" }, { "class" : "OCA\\DAV\\BulkUpload\\MultipartRequestParser", "file" : "/data/nextcloud/apps/dav/lib/BulkUpload/BulkUploadPlugin.php", "function" : "isAtLastBoundary", "line" : 71, "type" : "->" }, { "class" : "OCA\\DAV\\BulkUpload\\BulkUploadPlugin", "file" : "/data/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php", "function" : "httpPost", "line" : 89, "type" : "->" }, { "class" : "Sabre\\DAV\\Server", "file" : "/data/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php", "function" : "emit", "line" : 472, "type" : "->" }, { "class" : "Sabre\\DAV\\Server", "file" : "/data/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php", "function" : "invokeMethod", "line" : 253, "type" : "->" }, { "class" : "Sabre\\DAV\\Server", "file" : "/data/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php", "function" : "start", "line" : 321, "type" : "->" }, { "class" : "Sabre\\DAV\\Server", "file" : "/data/nextcloud/apps/dav/lib/Server.php", "function" : "exec", "line" : 360, "type" : "->" }, { "class" : "OCA\\DAV\\Server", "file" : "/data/nextcloud/apps/dav/appinfo/v2/remote.php", "function" : "exec", "line" : 35, "type" : "->" }, { "args" : [ "/data/nextcloud/apps/dav/appinfo/v2/remote.php" ], "file" : "/data/nextcloud/remote.php", "function" : "require_once", "line" : 167 } ], "exception" : {}, "message" : "Unknown error while seeking content" }, "level" : 3, "message" : "Unknown error while seeking content", "method" : "POST", "remoteAddr" : "*****", "reqId" : "Qrxj5bFNAAPoYgTYGy9B", "time" : "2022-10-25T13:43:09+00:00", "url" : "/cloud/remote.php/dav/bulk", "user" : "*****", "userAgent" : "Mozilla/5.0 (Linux) mirall/3.6.1git (Nextcloud, opensuse-tumbleweed-6.0.2-1-default ClientArchitecture: x86_64 OsArchitecture: x86_64)", "version" : "25.0.0.18" }Additional info
Under “Is this bug present after an update or on a fresh install?” I had to select something, although I did not update the client.
The text was updated successfully, but these errors were encountered: