Closed madpilot78 closed 4 years ago
using nextcloud-client-2.6.1-2-x86_64 from arch community repo
not sure if this is related, but i experience gnome-keyring-daemon "running amok" with latest version, it consumes lots of cpu, conky reports constantly 20-30M IO write (!!).
i have ~10 Folders "in sync" on 3 different Servers, strange behaviour stops as soon i "stop all synchronizations" and continues if i start it again.
downgrading to V2.6.0 fixes the problem
downgrading to V2.6.0 fixes the problem
The line I pointed out comes from this commit: 19491ff85f3cd02952478d2ee1fb42caf252e9dd
It is four months old, so it was included in 2.6.0 too. But I don't know if this is interacting with something else.
It is four months old, so it was included in 2.6.0 too. But I don't know if this is interacting with something else.
As far as I can tell, https://github.com/nextcloud/desktop/commit/19491ff85f3cd02952478d2ee1fb42caf252e9dd was only merged ~3 weeks ago ( #1504 ) and was only just included in the 2.6.1 release https://github.com/nextcloud/desktop/releases/tag/v2.6.1
I'm seeing what seems to be a related issue in which Nextcloud is continually trying to register the Default Keyring in gnome-keyring-daemon. (Arch Linux, nextcloud-client 2.6.1-2 x86_64). Downgrading to 2.6.0 solved the issue for me as well
This looks like a default behaviour caused by
I'm going to test compiling the client with that line commented out. I understand it's not a permanent fix, but will at least indicate if that line is actually the cause.
I can now confirm that commenting out the above line in the source code makes tha unwanted behaviour disappear.
I understand this is no fox. It looks like this was added to properly implement the "remote wipe" functionality, and I don't know the details of how that works.
Someone who knows that code should take a better look here.
using nextcloud-client-2.6.1-2-x86_64 from arch community repo
not sure if this is related, but i experience gnome-keyring-daemon "running amok" with latest version, it consumes lots of cpu, conky reports constantly 20-30M IO write (!!).
i have ~10 Folders "in sync" on 3 different Servers, strange behaviour stops as soon i "stop all synchronizations" and continues if i start it again.
downgrading to V2.6.0 fixes the problem
To add to this, when running nextcloud-client-2.6.1-2-x86_64 on my system, gnome-keyring-daemon entries are continuously spammed in my system log:
gnome-keyring-daemon[774]: asked to register item /org/freedesktop/secrets/collection/login/179, but it's already registered
gnome-keyring-daemon[774]: asked to register item /org/freedesktop/secrets/collection/login/178, but it's already registered
...
Again, V2.6.0 does not exhibit this.
I tried to delete all items in seahorse and re-register nexctloud client again, however, the spamming our system log continued. Downgrading. (Arch Linux).
I have a similar issue on macOS (10.13.6) and Nextcloud client 2.6.1. Lots of logs about nextcloud, securityd and Keychain:
Subsystem: com.apple.securityd Category: security_exception 23:26:52.738269 +0100 nextcloud UNIX error exception: 17
Subsystem: com.apple.securityd Category: policy 23:26:53.328110 +0100 trustd cert[0]: TemporalValidity =(path)[]> 0
Subsystem: com.apple.securityd Category: SecError 23:26:53.328731 +0100 nextcloud Trust evaluate failure: [leaf TemporalValidity]
Subsystem: com.apple.securityd Category: security_exception 23:26:55.856622 +0100 securityd MacOS error: -67050
Subsystem: com.apple.securityd Category: clientid 23:26:55.858304 +0100 securityd code requirement check failed (-67050), client is not Apple-signed
Subsystem: com.apple.securityd Category: security_exception 23:26:55.862179 +0100 nextcloud CSSM Exception: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
Subsystem: com.apple.securityd Category: integrity 23:26:55.883141 +0100 nextcloud possible duplicate, trying to delete invalid items
Subsystem: com.apple.securityd Category: integrity 23:26:55.883795 +0100 nextcloud no unique id, using 6 attributes from mDbAttributes
Subsystem: com.apple.securityd Category: integrity 23:26:55.889692 +0100 nextcloud duplicate item exception is real; throwing it on
Subsystem: com.apple.securityd Category: security_exception 23:26:55.905105 +0100 securityd MacOS error: -67050
Subsystem: com.apple.securityd Category: clientid 23:26:55.906420 +0100 securityd code requirement check failed (-67050), client is not Apple-signed
Subsystem: com.apple.securityd Category: atomicfile 23:26:55.918648 +0100 nextcloud 0x6040010e2700 commited /Users/me/Library/Keychains/login.keychain-db.sb-… to /Users/me/Library/Keychains/login.keychain-db
Subsystem: com.apple.securityd Category: servermode 23:26:55.919807 +0100 securityd keychain reference in server mode
After a few hours, macOS tells me that Nextcloud clients has written 200GB (!) of data on the hard drive (while only a couple of small text files have been modified).
Did you try the AppImage? Does the error still occur there too? https://download.nextcloud.com/desktop/releases/Linux/Nextcloud-2.6.1-x86_64.AppImage
@ldesgrange Which build of 2.6.1 did you install?
New release build for macOS 10.12+, notarized by Apple at 2019-11-16: https://download.nextcloud.com/desktop/releases/Mac/Installer/Nextcloud-2.6.1.20191105.pkg
Legacy build for macOS 10.10 - 10.11 with older Qt and OpenSSL, not notarized (previously used build chain): https://download.nextcloud.com/desktop/releases/Mac/Installer/Nextcloud-2.6.1.20191104-legacy.pkg
For Linux:
Did you try the AppImage? Does the error still occur there too? https://download.nextcloud.com/desktop/releases/Linux/Nextcloud-2.6.1-x86_64.AppImage
As I stated I'm using FreeBSD and compiling the FreeBSD port. The appimage is not an option for me.
Anyway I did identify the line of code causing this behaviour. I am unable to propose a full patch because I don't know how the remote wipe works. But it definitely needs some change to the line I reference in my first message.
Did you try the AppImage? Does the error still occur there too? https://download.nextcloud.com/desktop/releases/Linux/Nextcloud-2.6.1-x86_64.AppImage
yes, just tried and i can confirm, this version shows the exact same behaviour.
Did you try the AppImage? Does the error still occur there too?
@misch7 I can confirm this issue occurs on the AppImage as well. Both @madpilot78's workaround in https://github.com/nextcloud/desktop/issues/1592#issuecomment-552102211 and downgrading to 2.6.0 resolve the issue for me
Thanks @brrrrrrrt and @pwfrank ! It's helpful to know, that the issue occurs on the AppImage as well.
And thanks @madpilot78, we'll look into that.
@ldesgrange Which build of 2.6.1 did you install?
New release build for macOS 10.12+, notarized by Apple at 2019-11-16: https://download.nextcloud.com/desktop/releases/Mac/Installer/Nextcloud-2.6.1.20191105.pkg
Yes, I'm using that version: Version 2.6.1stable (build 20191105).
Same on Xubuntu 19.10
ii libnextcloudsync0 2.6.1-20191017.124538~eoan1 amd64 Nextcloud sync library
ii nextcloud-client 2.6.1-20191017.124538~eoan1 amd64 Nextcloud desktop sync client
ii nextcloud-client-l10n 2.6.1-20191017.124538~eoan1 all Nextcloud client internatialization files
/etc/rsyslog.d/10-nextcloud_client.conf:
:msg,contains,"asked to register item /org/freedesktop/secrets/collection/login/" ~
I have the same behavior with version 2.6.1(stable) for macOS. My macOS version is: 10.14.6 (18G1012) The client writes approx. 100 GB to the hard disk within approx. 8 hours. The following messages appear in the log of macOS every 2.5 seconds:
standard 16:04:24.664872 +0100 trustd asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (nextcloud[420]/0#-1 LF=0)
standard 16:04:24.707079 +0100 nextcloud CSSM Exception: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
standard 16:04:24.708908 +0100 nextcloud CSSM Exception: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
standard 16:04:24.710825 +0100 nextcloud CSSM Exception: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
standard 16:04:24.712520 +0100 nextcloud possible duplicate, trying to delete invalid items
standard 16:04:24.712882 +0100 nextcloud no unique id, using 6 attributes from mDbAttributes
standard 16:04:24.717640 +0100 nextcloud duplicate item exception is real; throwing it on
standard 16:04:24.717718 +0100 nextcloud caught CssmError during add: -2147413719 CSSMERR_DL_INVALID_UNIQUE_INDEX_DATA
standard 16:04:24.757442 +0100 nextcloud 0x6000035d1880 commited /Users/USER/Library/Keychains/login.keychain-db.sb-ea826489-sQ1OrK to /Users/USER/Library/Keychains/login.keychain-db
standard 16:04:24.779662 +0100 nextcloud 0x6000035d1800 commited /Users/USER/Library/Keychains/login.keychain-db.sb-ea826489-2ZmJPj to /Users/USER/Library/Keychains/login.keychain-db
standard 16:04:24.792280 +0100 trustd asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (nextcloud[420]/0#-1 LF=0)
standard 16:04:24.819734 +0100 nextcloud no previous integrity acl exists; making a new one
standard 16:04:24.844267 +0100 nextcloud 0x600003628200 commited /Users/USER/Library/Keychains/login.keychain-db.sb-ea826489-KYw1tL to /Users/USER/Library/Keychains/login.keychain-db
An attempt was made to reinstall the client (2.6.1) over the existing version as well as to completely delete and then reinstall the client (2.6.1). I also logged the client off and logged it back on to the server. This didn't bring any success. Additionally I closed the client, removed all entries from it in the macOS keychain by hand and registered it again on the server. This didn't bring any success either.
The only current solution was a downgrade to client version 2.5.3.
Just want to confirm the same logspam error on an fresh installed & updated Arch Linux. I didnt investigate it for now but can provide logs if needed.
While waiting for this to be fixed and released, can I ask where others are getting 2.6.0 debs from? (assuming you're using deb packages)
I'd prefer not to start using AppImages just for this :thinking:
Previous versions (but not 2.6.0) appear here: http://ppa.launchpad.net/nextcloud-devs/client/ubuntu/pool/main/n/nextcloud-client/
So far it looks like I'll need to build it myself or use Debian's repos.
As the cause has already been analyzed, this is OS independent. Nevertheless, confirmed for nextcloud-client-2.6.1-1.fc30.x86_64 (and I had been so happy that the new version finally appeared in the repos and the annoying update message subsided).
Problem confirmed with nextcloud-client-2.6.1-1.fc29.x86_64 as well.
This has been fixed by #1646.
Linux: Please use this AppImage build to test it: https://github.com/nextcloud/desktop/issues/1292#issuecomment-560008811
The fix will get into the 2.6.2 release.
@misch7 Thanks a lot for the fix!
After a quick test I can confirm it works fine on FreeBSD.
Expected behaviour
I expect the client to save the credentials when they are actually created or changed and then leave the information as is
Actual behaviour
I have noticed the keyring file is continuously updated, every few seconds. I noticed this because I keep my home directory in sync using unison, here is an excerpt from the log:
From the nextcloud client I found this repeatedly:
This looks like a default behaviour caused by https://github.com/nextcloud/desktop/blob/5775ec1ff1f3c65810d9c8ebd1f75b5280a0583d/src/gui/creds/webflowcredentials.cpp#L423
I'm going to test compiling the client with that line commented out. I understand it's not a permanent fix, but will at least indicate if that line is actually the cause.
Steps to reproduce
1.install 2.connect a nexcloud account
Client configuration
Client version: 2.6.1
Operating system: FreeBSD
OS language: Default (C - english)
Qt version used by client package (Linux only, see also Settings dialog):Qt 5.13.0
Client package (From Nextcloud or distro) (Linux only):FreeBSD nextcloud port updated to latest version
Installation path of client: default, /usr/local/
Server configuration
Nextcloud version:
Storage backend (external storage):
Logs
Please use Gist (https://gist.github.com/) or a similar code paster for longer logs.
Client logfile: Output of
nextcloud --logwindow
ornextcloud --logfile log.txt
(On Windows usingcmd.exe
, you might need to firstcd
into the Nextcloud directory) (See also https://docs.nextcloud.com/desktop/2.3/troubleshooting.html#log-files)Web server error log:
Server logfile: nextcloud log (data/nextcloud.log):