[Linux] [1.7.0] 100%CPU - no sync

hjrgit commented 9 years ago

Hi, after updating to 1.7.0 the ownCloud client unfortunately no longer works. Version 1.6.4 was running without any problems before.

Problem: 100% CPU
Problem: The owncloud-client is not synchronizing any more.

screenshot1

So I tried a "fresh" install: I have wiped all local files (synced folders & config-files) and refurbished the connection. The client is parsing the folders at the server, but nothing more; just 100%CPU.

screenshot2

Altough the screenshot says, that there is no connection, but I can see in the servers logfile the successfull login (otherwise the client would probably not read the servers folders ;-)

By the way: owncloudcmd is working without any errors.

At the moment I have no idea, what I could also try or what to check.

So, I would like to install 1.6.4 for the moment again, but cannot find the deb-packages somewhere. http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/xUbuntu_14.04/i386/ holds just 1.7.0 and in my local apt cache the files are replaced, too. Can I still download the 1.6.4 deb-packeges somewhere?

System: i386 Ubuntu 14.04.1 LTS (trusty)

moscicki commented 9 years ago

There is something similar on Mac: #2479

Did you try to install the client without overlay icons? You may choose that at the setup time.

Would this help?

hjrgit commented 9 years ago

hi,

yes, I have seen #2479 before, but I tought this is mac specific.

How can I choose the installation of the overlay icons? I did a normal apt-get upate && apt-get upgrade for the update from 1.6.4 to 1.7.0. There are no possibilities to select something.

Also I tried the mentioned "clean installation" by doing a "apt-get purge owncloud-client libowncloudsync* libneon27*" followed by an "apt-get install owncloud-client" (without the ability to deselect something because of the fixed package-dependencies)

But of course, I don't need any overlay icons, because I'm using xubuntu (xfce without any nautilus)

hjrgit commented 9 years ago

a little update: it looks like this would affect only our 32bit systems (i386). The issue is reproducible in all of these systems, while the 64bit systems (amd64) seem to be working very well.

guruz commented 9 years ago

@hjrgit But all of your systems running the same Linux distro?

If you run the client with --logfile - what does he seem to be working on?

hjrgit commented 9 years ago

hi,

yes, everywhere the actual xubuntu LTS-version (14.04.1).

When looking at the logfile, it seems, that "csync_ftw" and "csync_walker" take the most time. The Logfile is about 6MB in 30 sec. So I did a grep to find something like "error", "failure", "timeout" or similar. But I can't find any hint.

I'm attaching the logfile; maybe you are able to see something more. (Because the log file contains sensitive information, I have removed all the rows that contain file names)

The whole logged process repeated endlessly. From my amateur understanding, it looks as if the "walker" is indicating all files again and again and again...

On Mon, 17 Nov 2014, Markus Goetz wrote:

@hjrgit But all of your systems running the same Linux distro?

If you run the client with --logfile - what does he seem to be working on?

Reply to this email directly or view it on GitHub: https://github.com/owncloud/mirall/issues/2485#issuecomment-63350283 11-17 19:42:27:745 0x9bbc2c8 "################## ownCloud de_DE () 1.7.0" 11-17 19:42:27:746 0x9bbc2c8 void Mirall::Application::setupTranslations() Using "de_DE" translation 11-17 19:42:27:753 0x9bbc2c8 * Setup folders from "" 11-17 19:42:27:754 0x9bbc2c8 -> setting up: "ownCloud" 11-17 19:42:27:754 0x9bbc2c8 -> file path: "/home/hans/.local/share/data/ownCloud/folders/ownCloud" 11-17 19:42:27:755 0x9bbc2c8 Checked local path ok 11-17 19:42:27:755 0x9bbc2c8 setting remote poll timer interval to 30000 msec 11-17 19:42:27:755 0x9bbc2c8 Adding folder to Folder Map Mirall::Folder(0x9d797c0) 11-17 19:42:27:755 0x9bbc2c8 (+) Watcher: "/home/hans/cloudfiles/owncloud/" 11-17 19:42:27:991 0x9bbc2c8-> and 414 subdirectories 11-17 19:42:27:993 0x9bbc2c8 Schedule folder "ownCloud" to sync! 11-17 19:42:28:621 0x9bbc2c8 Sys Info size: 87 11-17 19:42:29:064 0x9bbc2c8 !!! Mirall::CheckServerJob created for QUrl( "https://XXXXXXXXX.de" ) querying "status.php" 11-17 19:42:29:492 0x9bbc2c8 status.php returns: QMap(("edition", QVariant(QString, "") ) ( "installed" , QVariant(QString, "true") ) ( "version" , QVariant(QString, "7.0.3.4") ) ( "versionstring" , QVariant(QString, "7.0.3") ) ) 0 Reply: QNetworkReplyImpl(0x9e23130) 11-17 19:42:29:492 0x9bbc2c8 \ Application: ownCloud found: QUrl( "https://XXXXXXXXX.de/status.php" ) with version "7.0.3" ( "7.0.3.4" ) 11-17 19:42:29:626 0x9bbc2c8 !!! Mirall::PropfindJob created for QUrl( "https://XXXXXXXXX.de" ) querying "/" 11-17 19:42:29:626 0x9bbc2c8 # checking for authentication settings. 11-17 19:42:29:993 0x9bbc2c8 FolderMan: Syncing is disabled, no scheduling. 11-17 19:42:30:813 0x9bbc2c8 !!! Mirall::CheckQuotaJob created for QUrl( "https://XXXXXXXXX.de" ) querying "/" 11-17 19:42:35:427 0x9bbc2c8 Folder in overallStatus Message: Mirall::Folder(0x9d797c0) with name "ownCloud" 11-17 19:42:37:714 0x9bbc2c8 Folder in overallStatus Message: Mirall::Folder(0x9d797c0) with name "ownCloud" 11-17 19:42:37:716 0x9bbc2c8 Schedule folder "ownCloud" to sync! 11-17 19:42:37:716 0x9bbc2c8 II> Sync for folder "ownCloud" already scheduled, do not enqueue! 11-17 19:42:37:716 0x9bbc2c8 Connection Validator Result: "Connected" 11-17 19:42:37:716 0x9bbc2c8 ######## Connection and Credentials are ok! 11-17 19:42:39:999 0x9bbc2c8 Folder in overallStatus Message: Mirall::Folder(0x9d797c0) with name "ownCloud" 11-17 19:42:40:000 0x9bbc2c8 Schedule folder "ownCloud" to sync! 11-17 19:42:40:001 0x9bbc2c8 II> Sync for folder "ownCloud" already scheduled, do not enqueue! 11-17 19:42:40:001 0x9bbc2c8 ######## connected to ownCloud Server! 11-17 19:42:42:306 0x9bbc2c8 Folder in overallStatus Message: Mirall::Folder(0x9d797c0) with name "ownCloud" 11-17 19:42:46:923 0x9bbc2c8 Folder in overallStatus Message: Mirall::Folder(0x9d797c0) with name "ownCloud" 11-17 19:42:46:939 0x9bbc2c8 XX slotScheduleFolderSync: folderQueue size: 1 11-17 19:42:46:941 0x9bbc2c8 Passing NO proxy to csync for "https://XXXXXXXXX.de" 11-17 19:42:49:281 0x9bbc2c8 Folder in overallStatus Message: Mirall::Folder(0x9d797c0) with name "ownCloud" 11-17 19:42:49:283 0x9bbc2c8 Sync state changed for folder "ownCloud" : "SyncPrepare" 11-17 19:42:49:284 0x9bbc2c8 ** Start syncing - client version 1.7.0 11-17 19:42:49:284 0x9bbc2c8 ==== added system ignore list to csync: "/etc/ownCloud/sync-exclude.lst" 11-17 19:42:49:284 0x9bbc2c8 csync_excludeload: Adding entry: .filepart 11-17 19:42:49:284 0x9bbc2c8 csync_exclude_load: Adding entry: ~ 11-17 19:42:49:284 0x9bbc2c8 csync_exclude_load: Adding entry: .part 11-17 19:42:49:284 0x9bbc2c8 csync_exclude_load: Adding entry: .crdownload 11-17 19:42:49:284 0x9bbc2c8 csync_excludeload: Adding entry: *.unison 11-17 19:42:49:285 0x9bbc2c8 csync_exclude_load: Adding entry: _csynctimedif.ctmp 11-17 19:42:49:285 0x9bbc2c8 csync_exclude_load: Adding entry: .csync_journal.db 11-17 19:42:49:285 0x9bbc2c8 csync_exclude_load: Adding entry: .csync_journal.db.ctmp 11-17 19:42:49:285 0x9bbc2c8 csync_exclude_load: Adding entry: .owncloudsync.log 11-17 19:42:49:285 0x9bbc2c8 csync_excludeload: Adding entry: ..sw? 11-17 19:42:49:285 0x9bbc2c8 csync_excludeload: Adding entry: .._sw? 11-17 19:42:49:285 0x9bbc2c8 csync_exclude_load: Adding entry: ].csync-progressdatabase 11-17 19:42:49:285 0x9bbc2c8 csync_exclude_load: Adding entry: ].DS_Store 11-17 19:42:49:285 0x9bbc2c8 csync_exclude_load: Adding entry: ].ds_store 11-17 19:42:49:285 0x9bbc2c8 csync_exclude_load: Adding entry: .__ 11-17 19:42:49:285 0x9bbc2c8 csync_exclude_load: Adding entry: ]Thumbs.db 11-17 19:42:49:285 0x9bbc2c8 csync_exclude_load: Adding entry: desktop.ini 11-17 19:42:49:285 0x9bbc2c8 csync_excludeload: Adding entry: .kate-swp 11-17 19:42:49:286 0x9bbc2c8 csync_exclude_load: Adding entry: conflict- 11-17 19:42:49:286 0x9bbc2c8 csync_excludeload: Adding entry: ].~_ 11-17 19:42:49:286 0x9bbc2c8 csync_exclude_load: Adding entry: ].TemporaryItems 11-17 19:42:49:286 0x9bbc2c8 csync_exclude_load: Adding entry: ].Trashes 11-17 19:42:49:286 0x9bbc2c8 csync_exclude_load: Adding entry: ].DocumentRevisions-V100 11-17 19:42:49:286 0x9bbc2c8 csync_exclude_load: Adding entry: .fseventd 11-17 19:42:49:286 0x9bbc2c8 csync_exclude_load: Adding entry: .apdisk 11-17 19:42:49:286 0x9bbc2c8 csync_exclude_load: Adding entry: .htaccess 11-17 19:42:49:286 0x9bbc2c8 csync_exclude_load: Adding entry: ]Icon\r 11-17 19:42:49:286 0x9bbc2c8 csync_exclude_load: Adding entry: ~$ 11-17 19:42:49:286 0x9bbc2c8 csync_exclude_load: Adding entry: .~lock. 11-17 19:42:49:287 0x9bbc2c8 csync_excludeload: Adding entry: ~.tmp 11-17 19:42:49:287 0x9bbc2c8 ==== added user defined ignore list to csync: "/home/hans/.local/share/data/ownCloud/sync-exclude.lst" 11-17 19:42:49:288 0x9bbc2c8 >===================================== sync started for "ownCloud" 11-17 19:42:49:288 0x9bbc2c8 ==== added system ignore list to socketapi: "/etc/ownCloud/sync-exclude.lst" 11-17 19:42:49:288 0x9bbc2c8 csync_exclude_load: Adding entry: .filepart 11-17 19:42:49:288 0x9bbc2c8 csync_exclude_load: Adding entry: ~ 11-17 19:42:49:288 0x9bbc2c8 csync_exclude_load: Adding entry: .part 11-17 19:42:49:288 0x9bbc2c8 csync_exclude_load: Adding entry: .crdownload 11-17 19:42:49:288 0x9bbc2c8 csync_excludeload: Adding entry: *.unison 11-17 19:42:49:289 0x9bbc2c8 csync_exclude_load: Adding entry: _csynctimedif.ctmp 11-17 19:42:49:289 0x9bbc2c8 csync_exclude_load: Adding entry: .csync_journal.db 11-17 19:42:49:289 0x9bbc2c8 csync_exclude_load: Adding entry: .csync_journal.db.ctmp 11-17 19:42:49:289 0x9bbc2c8 csync_exclude_load: Adding entry: .owncloudsync.log 11-17 19:42:49:289 0x9bbc2c8 csync_excludeload: Adding entry: ..sw? 11-17 19:42:49:289 0x9bbc2c8 csync_excludeload: Adding entry: .._sw? 11-17 19:42:49:289 0x9bbc2c8 csync_exclude_load: Adding entry: ].csync-progressdatabase 11-17 19:42:49:289 0x9bbc2c8 csync_exclude_load: Adding entry: ].DS_Store 11-17 19:42:49:289 0x9bbc2c8 csync_exclude_load: Adding entry: ].ds_store 11-17 19:42:49:289 0x9bbc2c8 csync_exclude_load: Adding entry: .__ 11-17 19:42:49:289 0x9bbc2c8 csync_exclude_load: Adding entry: ]Thumbs.db 11-17 19:42:49:289 0x9bbc2c8 csync_exclude_load: Adding entry: desktop.ini 11-17 19:42:49:289 0x9bbc2c8 csync_excludeload: Adding entry: .kate-swp 11-17 19:42:49:290 0x9bbc2c8 csync_exclude_load: Adding entry: conflict- 11-17 19:42:49:290 0x9bbc2c8 csync_excludeload: Adding entry: ].~_ 11-17 19:42:49:290 0x9bbc2c8 csync_exclude_load: Adding entry: ].TemporaryItems 11-17 19:42:49:290 0x9bbc2c8 csync_exclude_load: Adding entry: ].Trashes 11-17 19:42:49:290 0x9bbc2c8 csync_exclude_load: Adding entry: ].DocumentRevisions-V100 11-17 19:42:49:290 0x9bbc2c8 csync_exclude_load: Adding entry: .fseventd 11-17 19:42:49:290 0x9bbc2c8 csync_exclude_load: Adding entry: .apdisk 11-17 19:42:49:290 0x9bbc2c8 csync_exclude_load: Adding entry: .htaccess 11-17 19:42:49:290 0x9bbc2c8 csync_exclude_load: Adding entry: ]Icon\r 11-17 19:42:49:290 0x9bbc2c8 csync_exclude_load: Adding entry: ~$ 11-17 19:42:49:290 0x9bbc2c8 csync_exclude_load: Adding entry: .~lock. 11-17 19:42:49:291 0x9bbc2c8 csync_exclude_load: Adding entry: ~.tmp 11-17 19:42:49:291 0x9bbc2c8 ==== added user defined ignore list to csync: "/home/hans/.local/share/data/ownCloud/sync-exclude.lst" 11-17 19:42:49:291 0x9bbc2c8 Currently folder "ownCloud" is running, wait for finish! 11-17 19:42:49:291 0x9bbc2c8 Currently folder "ownCloud" is running, wait for finish! 11-17 19:42:49:291 0x9bbc2c8 Mirall::CheckQuotaJob(0x9d68f08) Timeout 11-17 19:42:49:291 0x9bbc2c8 void Mirall::AbstractNetworkJob::slotFinished() 5 "Operation abgebrochen" 11-17 19:42:49:296 0x9bbc2c8 folder "ownCloud" Terminating! 11-17 19:42:49:302 0x9bbc2c8 Client is on latest version! 11-17 19:42:49:302 0x9bbc2c8 =====sync with existing DB 11-17 19:42:49:304 0x9bbc2c8 sqlite3 version "3.8.2" 11-17 19:42:49:305 0x9bbc2c8 sqlite3 journal_mode= "wal" 11-17 19:42:49:306 0x9bbc2c8 void Mirall::SyncJournalDb::commitInternal(const QString&, bool) Transaction commit "checkConnect" and starting new transaction 11-17 19:42:49:307 0x9bbc2c8 Columns in the current journal: ("phash", "pathlen", "path", "inode", "uid", "gid", "mode", "modtime", "type", "md5", "fileid", "remotePerm") 11-17 19:42:49:307 0x9bbc2c8 void Mirall::SyncJournalDb::commitInternal(const QString&, bool) Transaction commit "update database structure: add inode index" and starting new transaction 11-17 19:42:49:308 0x9bbc2c8 void Mirall::SyncJournalDb::commitInternal(const QString&, bool) Transaction commit "update database structure: add pathlen index" and starting new transaction 11-17 19:42:49:309 0x9bbc2c8 void Mirall::SyncJournalDb::commitInternal(const QString&, bool) Transaction commit "checkConnect End"
11-17 19:42:49:310 0x9bbc2c8 ====Using Selective Sync 11-17 19:42:49:311 0x9bbc2c8 #### Discovery start #################################################### >> 11-17 19:42:49:311 0x9e03894 csync_update: Journal: /home/hans/cloudfiles/owncloud/.csync_journal.db 11-17 19:42:49:406 0x9e03894 csync_statedb_load: sqlite3 version "3.8.2" 11-17 19:42:49:407 0x9e03894 csync_statedb_load: Success 11-17 19:42:49:407 0x9e03894 csync_memstat_check: Memory: 187524K total size, 35572K resident, 24908K shared 11-17 19:42:49:408 0x9e03894 sqlite_profile: SQL SELECT \ FROM metadata WHERE phash=?1: 0 11-17 19:42:49:408 0x9e03894 csync_walker: file: /home/hans/cloudfiles/owncloud/.csync_journal.db.old [inode=3473418 size=1328128] 11-17 19:42:49:409 0x9e03894 csync_ftw: Uniq ID from Database: XXXXXXXXXXXXXXX -> 5469d2bad3045 11-17 19:42:49:409 0x9e03894 csync_walker: file: /home/hans/cloudfiles/owncloud/XXXXXXXXXXXXXXX [inode=3474503 size=2045440] [...] deleted about 37000 lines [...] 11-17 19:42:58:956 0x9bbc2c8 Mirall::SyncJournalFileRecord::SyncJournalFileRecord(const Mirall::SyncFileItem&, const QString&) "/home/hans/cloudfiles/owncloud/XXXXXXXXXXXXXXXX" Retrieved inode 3514622 (previous item inode: 3514622 ) 11-17 19:42:58:956 0x9bbc2c8 "INSERT OR REPLACE INTO metadata (phash, pathlen, path, inode, uid, gid, mode, modtime, type, md5, fileid, remotePerm) VALUES (?1 , ?2, ?3 , ?4 , ?5 , ?6 , ?7, ?8 , ?9 , ?10, ?11, ?12);" -682169567284442464 16 "XXXXXXXXXXXXXXXX" 3514622 0 "1413282211" "2" "543cf9a361ab9" "0002035952033fe4c05e6" "RDNVCK" 11-17 19:42:59:100 0x9bbc2c8 void Mirall::SyncJournalDb::walCheckpoint() took 0 msec 11-17 19:42:59:101 0x9bbc2c8 void Mirall::SyncJournalDb::commitInternal(const QString&, bool) Transaction commit "All Finished."
11-17 19:42:59:144 0x9bbc2c8 CSync run took 9834 11-17 19:42:59:147 0x9bbc2c8 -> SyncEngine finished without problem. 11-17 19:42:59:147 0x9bbc2c8 Processing result list and logging took 0 Milliseconds. 11-17 19:42:59:148 0x9bbc2c8 OO folder slotSyncFinished: result: 3 11-17 19:42:59:159 0x9bbc2c8 Sync state changed for folder "ownCloud" : "Success" 11-17 19:42:59:368 0x9bbc2c8 <===================================== sync finished for "" 11-17 19:42:59:568 0x9bbc2c8 FolderMan: Syncing is disabled, no scheduling. 11-17 19:43:01:572 0x9bbc2c8 Saving 0 unknown certs. 11-17 19:43:01:572 0x9bbc2c8 void Mirall::SyncJournalDb::close() "/home/hans/cloudfiles/owncloud/.csync_journal.db" 11-17 19:43:01:573 0x9bbc2c8 No database Transaction to commit 11-17 19:43:01:701 0x9bbc2c8 "/home/hans/.local/share/data//ownCloud//cookies.db" 11-17 19:43:01:705 0x9bbc2c8 SocketApi: dtor

guruz commented 9 years ago

Could you also paste the logfile between two syncs? Basically what happens from CSync run took to next *** Start syncing - client version 1.7.0? Thanks

guruz commented 9 years ago

Could you also tell me the size of your .csync_journal.db? sqlite3 /path/to/sync/folder/.csync_journal.db .dump | wc -l

hjrgit commented 9 years ago

of course. The size of the .db file is 6078. The requested lines of the logfile are attached.

On Mon, 17 Nov 2014, Markus Goetz wrote:

Could you also paste the logfile between two syncs? Basically what happens from CSync run took to next *** Start syncing - client version 1.7.0? Thanks

Reply to this email directly or view it on GitHub: https://github.com/owncloud/mirall/issues/2485#issuecomment-63370733 11-17 21:38:38:257 0x8b262c8 CSync run took 10308 11-17 21:38:38:259 0x8b262c8 -> SyncEngine finished without problem. 11-17 21:38:38:260 0x8b262c8 Processing result list and logging took 0 Milliseconds. 11-17 21:38:38:260 0x8b262c8 OO folder slotSyncFinished: result: 3 11-17 21:38:38:272 0x8b262c8 Sync state changed for folder "ownCloud" : "Success" 11-17 21:38:38:483 0x8b262c8 <===================================== sync finished for "" 11-17 21:38:38:683 0x8b262c8 FolderMan: Syncing is disabled, no scheduling. 11-17 21:38:59:934 0x8b262c8 !!! Mirall::CheckServerJob created for QUrl( "https://XXXXXXXXXXde" ) querying "status.php" 11-17 21:39:00:389 0x8b262c8 status.php returns: QMap(("edition", QVariant(QString, "") ) ( "installed" , QVariant(QString, "true") ) ( "version" , QVariant(QString, "7.0.3.4") ) ( "versionstring" , QVariant(QString, "7.0.3") ) ) 0 Reply: QNetworkReplyImpl(0x8d8ae88) 11-17 21:39:00:390 0x8b262c8 * Application: ownCloud found: QUrl( "https://XXXXXXXXX.de/status.php" ) with version "7.0.3" ( "7.0.3.4" ) 11-17 21:39:00:391 0x8b262c8 !!! Mirall::PropfindJob created for QUrl( "https://XXXXXXXXX.de" ) querying "/" 11-17 21:39:00:391 0x8b262c8 # checking for authentication settings. 11-17 21:39:00:733 0x8b262c8 !!! Mirall::CheckQuotaJob created for QUrl( "https://XXXXXXXXX.de" ) querying "/" 11-17 21:39:05:485 0x8b262c8 Folder in overallStatus Message: Mirall::Folder(0x8d08590) with name "ownCloud" 11-17 21:39:07:846 0x8b262c8 Folder in overallStatus Message: Mirall::Folder(0x8d08590) with name "ownCloud" 11-17 21:39:07:848 0x8b262c8 Schedule folder "ownCloud" to sync! 11-17 21:39:07:848 0x8b262c8 Connection Validator Result: "Connected" 11-17 21:39:07:848 0x8b262c8 ######## Connection and Credentials are ok! 11-17 21:39:10:199 0x8b262c8 Folder in overallStatus Message: Mirall::Folder(0x8d08590) with name "ownCloud" 11-17 21:39:10:200 0x8b262c8 Schedule folder "ownCloud" to sync! 11-17 21:39:10:200 0x8b262c8 II> Sync for folder "ownCloud" already scheduled, do not enqueue! 11-17 21:39:10:201 0x8b262c8 ######## connected to ownCloud Server! 11-17 21:39:12:554 0x8b262c8 Folder in overallStatus Message: Mirall::Folder(0x8d08590) with name "ownCloud" 11-17 21:39:17:266 0x8b262c8 Folder in overallStatus Message: Mirall::Folder(0x8d08590) with name "ownCloud" 11-17 21:39:17:283 0x8b262c8 \ Polling "ownCloud" for changes. (time since last sync: 39 s) 11-17 21:39:17:286 0x8b262c8 !!! Mirall::RequestEtagJob created for QUrl( "https://XXXXXXXXX.de" ) querying "" 11-17 21:39:17:286 0x8b262c8 XX slotScheduleFolderSync: folderQueue size: 1 11-17 21:39:17:286 0x8b262c8 Passing NO proxy to csync for "https://XXXXXXXXX.de" 11-17 21:39:19:686 0x8b262c8 Folder in overallStatus Message: Mirall::Folder(0x8d08590) with name "ownCloud" 11-17 21:39:19:687 0x8b262c8 Sync state changed for folder "ownCloud" : "SyncPrepare" 11-17 21:39:19:687 0x8b262c8 *\ Start syncing - client version 1.7.0

ckamm commented 9 years ago

11-17 21:38:38:483 0x8b262c8 <===================================== sync finished for "" 11-17 21:38:38:683 0x8b262c8 FolderMan: Syncing is disabled, no scheduling.

That looks odd! 1) currentSyncFolder == "" ! 2) As far as I know syncing should only be disabled on user action or connection loss - but the sync seemed to have finished successfully at the same time.

The next sync was likely triggered when setSyncEnabled(true) was called.

@hjrgit If you have a longer log file, maybe uploading something like "grep -i 'folder|sync finished|Start syncing'" on it would help us track this down.

ckamm commented 9 years ago

1) seems to be a confusing log message, not something that's completely broken.

Current guess: The Account thinks you are disconnected (screenshot shows disconnected state) and therefore disables sync and calls terminateSyncProcess (slotToggleFolderman). The sync finishes anyway (possible, maybe because it was almost done already? but sounds unlikely!) and eventually connection is reestablished (etag, quota or connectionvalidator) triggering another sync.

hjrgit commented 9 years ago

sorry for delay - my day was a little bit busy. The requested and filtered log is attached. I hope it is helpfull.

On Fri, 21 Nov 2014, ckamm wrote:

11-17 21:38:38:483 0x8b262c8 <===================================== sync finished for "" 11-17 21:38:38:683 0x8b262c8 FolderMan: Syncing is disabled, no scheduling.

That looks odd! 1) currentSyncFolder == "" ! 2) As far as I know syncing should only be disabled on user action or connection loss - but the sync seemed to have finished successfully at the same time.

The next sync was likely triggered when setSyncEnabled(true) was called.

@hjrgit If you have a longer log file, maybe uploading something like "grep -i 'folder|sync finished|Start syncing'" on it would help us track this down.

Reply to this email directly or view it on GitHub: https://github.com/owncloud/mirall/issues/2485#issuecomment-63947786 11-21 18:55:55:440 0x95e72c8 * Setup folders from "" 11-21 18:55:55:443 0x95e72c8 -> file path: "/home/hans/.local/share/data/ownCloud/folders/ownCloud" 11-21 18:55:55:444 0x95e72c8 Adding folder to Folder Map Mirall::Folder(0x96435d0) 11-21 18:55:55:689 0x95e72c8 Schedule folder "ownCloud" to sync! 11-21 18:55:57:774 0x95e72c8 FolderMan: Syncing is disabled, no scheduling. 11-21 18:56:03:877 0x95e72c8 Folder in overallStatus Message: Mirall::Folder(0x96435d0) with name "ownCloud" 11-21 18:56:06:166 0x95e72c8 Folder in overallStatus Message: Mirall::Folder(0x96435d0) with name "ownCloud" 11-21 18:56:06:167 0x95e72c8 Schedule folder "ownCloud" to sync! 11-21 18:56:06:167 0x95e72c8 II> Sync for folder "ownCloud" already scheduled, do not enqueue! 11-21 18:56:08:455 0x95e72c8 Folder in overallStatus Message: Mirall::Folder(0x96435d0) with name "ownCloud" 11-21 18:56:08:456 0x95e72c8 Schedule folder "ownCloud" to sync! 11-21 18:56:08:456 0x95e72c8 II> Sync for folder "ownCloud" already scheduled, do not enqueue! 11-21 18:56:10:739 0x95e72c8 Folder in overallStatus Message: Mirall::Folder(0x96435d0) with name "ownCloud" 11-21 18:56:15:309 0x95e72c8 Folder in overallStatus Message: Mirall::Folder(0x96435d0) with name "ownCloud" 11-21 18:56:15:324 0x95e72c8 XX slotScheduleFolderSync: folderQueue size: 1 11-21 18:56:17:700 0x95e72c8 Folder in overallStatus Message: Mirall::Folder(0x96435d0) with name "ownCloud" 11-21 18:56:17:701 0x95e72c8 Sync state changed for folder "ownCloud" : "SyncPrepare" 11-21 18:56:17:701 0x95e72c8 * Start syncing - client version 1.7.0 11-21 18:56:17:708 0x95e72c8 Currently folder "ownCloud" is running, wait for finish! 11-21 18:56:17:709 0x95e72c8 Currently folder "ownCloud" is running, wait for finish! 11-21 18:56:17:712 0x95e72c8 folder "ownCloud" Terminating! 11-21 18:56:26:773 0x95e72c8 Sync state changed for folder "ownCloud" : "Sync Running" 11-21 18:56:27:332 0x95e72c8 OO folder slotSyncFinished: result: 3 11-21 18:56:27:343 0x95e72c8 Sync state changed for folder "ownCloud" : "Success" 11-21 18:56:27:553 0x95e72c8 <===================================== sync finished for "" 11-21 18:56:27:753 0x95e72c8 FolderMan: Syncing is disabled, no scheduling. 11-21 18:56:55:278 0x95e72c8 Folder in overallStatus Message: Mirall::Folder(0x96435d0) with name "ownCloud" 11-21 18:56:57:660 0x95e72c8 Folder in overallStatus Message: Mirall::Folder(0x96435d0) with name "ownCloud" 11-21 18:56:57:661 0x95e72c8 Schedule folder "ownCloud" to sync! 11-21 18:57:00:041 0x95e72c8 Folder in overallStatus Message: Mirall::Folder(0x96435d0) with name "ownCloud" 11-21 18:57:00:042 0x95e72c8 Schedule folder "ownCloud" to sync! 11-21 18:57:00:042 0x95e72c8 II> Sync for folder "ownCloud" already scheduled, do not enqueue! 11-21 18:57:02:415 0x95e72c8 Folder in overallStatus Message: Mirall::Folder(0x96435d0) with name "ownCloud" 11-21 18:57:07:125 0x95e72c8 Folder in overallStatus Message: Mirall::Folder(0x96435d0) with name "ownCloud" 11-21 18:57:07:144 0x95e72c8 XX slotScheduleFolderSync: folderQueue size: 1 11-21 18:57:09:510 0x95e72c8 Folder in overallStatus Message: Mirall::Folder(0x96435d0) with name "ownCloud" 11-21 18:57:09:511 0x95e72c8 Sync state changed for folder "ownCloud" : "SyncPrepare" 11-21 18:57:09:511 0x95e72c8 * Start syncing - client version 1.7.0 11-21 18:57:09:519 0x95e72c8 Currently folder "ownCloud" is running, wait for finish! 11-21 18:57:09:522 0x95e72c8 folder "ownCloud" Terminating! 11-21 18:57:10:344 0x95e72c8 Schedule folder "ownCloud" to sync! 11-21 18:57:12:347 0x95e72c8 XX slotScheduleFolderSync: folderQueue size: 1 11-21 18:57:18:719 0x95e72c8 Sync state changed for folder "ownCloud" : "Sync Running" 11-21 18:57:19:226 0x95e72c8 OO folder slotSyncFinished: result: 3 11-21 18:57:19:237 0x95e72c8 Sync state changed for folder "ownCloud" : "Success" 11-21 18:57:19:446 0x95e72c8 <===================================== sync finished for "ownCloud" 11-21 18:57:19:647 0x95e72c8 XX slotScheduleFolderSync: folderQueue size: 0

ghost commented 9 years ago

I've the same problem, with Ubuntu 14.04, client 1.7.0 and owncloud 7.0.3.

The status turns to "disconnect from server" while syncing
All icons turns into grey
The sync seems to continue on server side (100% CPU)
The sync is aborted on client and/or the client crashes (core dump)

If I can help, just tell me what you need. This is really easy to replicate (it crashes every time after less than 5 min)

ghost commented 9 years ago

My issue was initially reported here : #2534 (with video)

ogoffart commented 9 years ago

One way to detect where the CPU is spend is to run mirall with gdb, and when there is 99% cpu usage, press ctrl+c, and enter thread apply all bt and get all the backtraces. then continue with continue and press ctrl+c again and run the command again to sample the backtrace. And we can see what the client is doing while taking the CPU.

hjrgit commented 9 years ago

hi,

I'm sorry, I'm not a software developer and I have no idea how to use/start the debugger in the right way. But, as mentioned above, the CPU is at 100%, while the "walker" checks my 5000 files over and over again.

On Mon, 1 Dec 2014, Olivier Goffart wrote:

One way to detect where the CPU is spend is to run mirall with gdb, and when there is 99% cpu usage, press ctrl+c, and enter thread apply all bt and get all the backtraces. then continue with continue and press ctrl+c again and run the command again to sample the backtrace. And we can see what the client is doing while taking the CPU.

Reply to this email directly or view it on GitHub: https://github.com/owncloud/mirall/issues/2485#issuecomment-65068719

guruz commented 9 years ago

(wrong comment, ment to comment here https://github.com/owncloud/mirall/issues/2534#issuecomment-65309130 )

ghost commented 9 years ago

Just to be precise : my 100% CPU is on the server side (raspberry PI), not on the client side. I'm not sure it is the same for hjrgit

guruz commented 9 years ago

@ckamm @ogoffart Maybe you haven't seen it from the log above:

11-17 19:42:30:813 0x9bbc2c8 !!! Mirall::CheckQuotaJob created for  QUrl( "https://XXXXXXXXX.de" )  querying "/"
11-17 19:42:49:291 0x9bbc2c8 Mirall::CheckQuotaJob(0x9d68f08) Timeout

This then might have aborted the sync(?).

ckamm commented 9 years ago

@guruz Yes, a failing CheckQuotaJob changes the Account's state to Disconnected and that ends up calling FolderMan::terminateSyncProcess().

It's really odd that the CheckQuotaJob would time out a couple of milliseconds after a sync run starts. But that seems to be what's going on in hjrgit's first log and probably also, twice, in his second log. I'll look at that part of the code.

ckamm commented 9 years ago

@hjrgit I saw that the CheckServerJob finishes really quickly (<500ms) but CheckQuotaJob timeouts after 19 seconds. What kind of server are you running? And what kind of storage do you use? Is it conceivable that the quota calculation will actually take that long?

We'll probably increase the quota job's timeout and not make its failure disconnect the whole account. That should solve this issue.

hjrgit commented 9 years ago

I don't think, that this is a problem on the server side: 4 xeon cores, the storage is a lun hosted on a FC-NetApp. And there is no recognizable load (neither cpu nor IO) while the client is running.

Everything was fine until the client-update from 1.6.4 to 1.7.0, which was the only change. The server is still the same.

The 1.7.0 64bit-clients are still working fine. "Only" the 32bit clients doesn't work. As workaround, we are using owncloudcmd to sync the files of the 32bit clients; this is working, but very uncomfortable and therfore not a permanent solution.

On Wed, 3 Dec 2014, ckamm wrote:

@hjrgit I saw that the CheckServerJob finishes really quickly (<500ms) but CheckQuotaJob timeouts after 19 seconds. What kind of server are you running? And what kind of storage do you use? Is it conceivable that the quota calculation will actually take that long?

We'll probably increase the quota job's timeout and not make its failure disconnect the whole account. That should solve this issue.

Reply to this email directly or view it on GitHub: https://github.com/owncloud/mirall/issues/2485#issuecomment-65374409

ckamm commented 9 years ago

@hjrgit Client version 1.7.0 added a 15s timeout to the quota job and uses it to detect whether the server is still available. It could very well be that the quota jobs always took a while, it just wasn't a problem for 1.6.4. I have no idea why 64bit clients would not be affected.

If you're using basic auth, could you try making this request:

    curl https://YOURSERVER/remote.php/webdav/ --user YOURUSER -X PROPFIND -d '<?xml version="1.0" ?><d:propfind xmlns:d="DAV:"><d:prop><d:quota-available-bytes/><d:quota-used-bytes/></d:prop></d:propfind>' -v --trace-time

And check how much time passes between request and response?

hjrgit commented 9 years ago

the whole process takes less then a second (incl. ssl-handshake etc.). Log is attached.

On Wed, 3 Dec 2014, ckamm wrote:

@hjrgit Client version 1.7.0 added a 15s timeout to the quota job and uses it to detect whether the server is still available. It could very well be that the quota jobs always took a while, it just wasn't a problem for 1.6.4. I have no idea why 64bit clients would not be affected.

If you're using basic auth, could you try making this request:
   curl https://YOURSERVER/remote.php/webdav/ --user YOURUSER -X PROPFIND -d '<?xml version="1.0" ?><d:propfind xmlns:d="DAV:"><d:prop><d:quota-available-bytes/><d:quota-used-bytes/></d:prop></d:propfind>' -v --trace-time
And check how much time passes between request and response?

Reply to this email directly or view it on GitHub: https://github.com/owncloud/mirall/issues/2485#issuecomment-65387225 $ curl https://xxxxx.xxx.xx/remote.php/webdav/ --user xxxx -X PROPFIND -d '<?xml version="1.0" ?>/d:prop/d:propfind' -v --trace-time Enter host password for user 'xxxx': 19:10:28.273058 * Hostname was NOT found in DNS cache 19:10:28.286320 * Trying xxx.xxx.xxx.xx... 19:10:28.336860 * Connected to xxxxx.xxx.xx (xxx.xxx.xxx.xx) port 443 (#0) 19:10:28.338411 * successfully set certificate verify locations: 19:10:28.338507 * CAfile: none CApath: /etc/ssl/certs 19:10:28.338928 * SSLv3, TLS handshake, Client hello (1): 19:10:28.400625 * SSLv3, TLS handshake, Server hello (2): 19:10:28.403602 * SSLv3, TLS handshake, CERT (11): 19:10:28.423079 * SSLv3, TLS handshake, Server key exchange (12): 19:10:28.426440 * SSLv3, TLS handshake, Server finished (14): 19:10:28.477019 * SSLv3, TLS handshake, Client key exchange (16): 19:10:28.477415 * SSLv3, TLS change cipher, Client hello (1): 19:10:28.478205 * SSLv3, TLS handshake, Finished (20): 19:10:28.530807 * SSLv3, TLS change cipher, Client hello (1): 19:10:28.531277 * SSLv3, TLS handshake, Finished (20): 19:10:28.531440 * SSL connection using DHE-RSA-AES256-GCM-SHA384 19:10:28.531546 * Server certificate: 19:10:28.531672 * subject: OU=Domain Control Validated; OU=PositiveSSL; CN=xxxxx.xxx.xx 19:10:28.531762 * start date: 2012-08-21 00:00:00 GMT 19:10:28.531846 * expire date: 2015-08-21 23:59:59 GMT 19:10:28.531987 * subjectAltName: xxxxx.xxx.xx matched 19:10:28.532171 * issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA 19:10:28.532258 * SSL certificate verify ok. 19:10:28.532386 * Server auth using Basic with user 'xxxx' 19:10:28.532657 > PROPFIND /remote.php/webdav/ HTTP/1.1 19:10:28.532657 > Authorization: Basic xxxx 19:10:28.532657 > User-Agent: curl/7.35.0 19:10:28.532657 > Host: xxxxx.xxx.xx 19:10:28.532657 > Accept: / 19:10:28.532657 > Content-Length: 126 19:10:28.532657 > Content-Type: application/x-www-form-urlencoded 19:10:28.532657 > 19:10:28.533176 * upload completely sent off: 126 out of 126 bytes 19:10:29.136757 < HTTP/1.1 207 Multi-Status 19:10:29.136938 < Date: Wed, 03 Dec 2014 18:10:28 GMT 19:10:29.137066 * Server Apache is not blacklisted 19:10:29.137181 < Server: Apache 19:10:29.137297 < X-Powered-By: PHP/5.3.10-1ubuntu3.15 19:10:29.137417 < Set-Cookie: xxxx; path=/; HttpOnly 19:10:29.137536 < Expires: Thu, 19 Nov 1981 08:52:00 GMT 19:10:29.137656 < Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 19:10:29.137777 < Pragma: no-cache 19:10:29.137895 < Strict-Transport-Security: max-age=31536000 19:10:29.138012 < X-XSS-Protection: 1; mode=block 19:10:29.138128 < X-Content-Type-Options: nosniff 19:10:29.138245 < X-Frame-Options: Sameorigin 19:10:29.138367 < Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-src ; img-src ; font-src 'self' data:; media-src * 19:10:29.138488 < X-Robots-Tag: none 19:10:29.138606 < Set-Cookie: xxxx; path=/; secure; HttpOnly 19:10:29.138726 < Vary: Brief,Prefer 19:10:29.138843 < DAV: 1, 3, extended-mkcol, 2 19:10:29.138978 < Content-Length: 2885 19:10:29.139101 < Content-Type: application/xml; charset=utf-8 19:10:29.139219 < <?xml version="1.0" encoding="utf-8"?> <d:multistatus xmlns:d="DAV:" [...]
SDNVCK/oc:permissions5206445275/d:quota-available-bytes155784112/d:quota-used-bytes/d:propHTTP/1.1 200 OK/d:status/d:propstat/d:response/d:multistatus 19:10:29.140117 \* Connection #0 to host xxxxx.xxx.xx left intact $

ckamm commented 9 years ago

Thank you @hjrgit. That means the quota job should finish quickly, not time out after 19 seconds. The only thing related to 32 bits that I see is that your quota-bytes-available doesn't fit a 32 bit integer. But the client's reading code seems to deal with that just fine.

guruz commented 9 years ago

@hjrgit Do you want to try a new nightly version? https://software.opensuse.org/download/package?project=isv:ownCloud:community:nightly&package=owncloud-client

hjrgit commented 9 years ago

of course. I have removed 1.7.0 and installed the nightly just now. But unfortunately, the behavior is exactly the same.

On Fri, 5 Dec 2014, Markus Goetz wrote:

@hjrgit Do you want to try a new nightly version? https://software.opensuse.org/download/package?project=isv:ownCloud:community:nightly&package=owncloud-client

Reply to this email directly or view it on GitHub: https://github.com/owncloud/mirall/issues/2485#issuecomment-65788346

dragotin commented 9 years ago

I do run a client on a 32 bit Mint linux distro, works perfectly, no CPU issue so far.

ghost commented 9 years ago

@ckamm I also tried your curl command on my configuration.

It takes 10 seconds to respond.... with one user active on the server...

If there is 2 users syncing at the same time (check via the command iftop bandwidth monitor), it takes between 20 and 45 seconds....

I would really appreciate that this time out value is increased, in order to reduce the deconnections coming from a busy server (Raspberry Pi / Raspbian / Ligghtpd / mysql)

ckamm commented 9 years ago

@stephane84 A recent 1.7 build will have the quota timeout set to 5min, could you try with that? Since you confirmed that quota requests can be slow, we'll also talk about merging https://github.com/ckamm/mirall/tree/quota-slow which would make the connection status not tied to the quota job.

tpokorra commented 9 years ago

I have the same problem, that the client says it does not have a connection ("Keine Verbindung mit ownCloud zu ..."). I am using 32 bit Ubuntu 12.04. The curl command returns really fast, so no timeout issue there for me. My quota available is also too big for 32 bit integer: <d:quota-available-bytes>14360392070</d:quota-available-bytes> Since the nightly build for 12.04 has been disabled, I have branched the project on OBS and built it for myself: https://build.opensuse.org/package/show/home:tpokorra:branches:isv:ownCloud:community:nightly/owncloud-client Unfortunately, that build fails ([ 855s] /usr/lib/gcc/i686-linux-gnu/4.6/../../../../lib/libneon.so: undefined reference to `SSLv2_server_method'), so I cannot test the nightly build.

ckamm commented 9 years ago

@tpokorra @hjrgit It seems unlikely but we're out of guesses right now: Maybe there's a bug with quota processing? Could you run something like this while the client is running:

wireshark -i <interface> -k -Y '(xml.tag == "<d:quota-available-bytes/>") || (xml.tag == "<d:quota-available-bytes>")'

Where is eth0 or whatever interface communication with the oC server runs on. This should show you the quota requests and their responses. One should pop up every 30 seconds. What's the time difference between the request and the response? ("PROPFIND" is the request, "207 Multi-Status" is the response)

If the request is actually responded to quickly, there's a processing issue in the client.

tpokorra commented 9 years ago

I had to disable ssl for wireshark to be able to see the content of the communication with the server. Now the client behaves, and shows that it is able to connect to the server. It also shows the Quota correct (20GB). The time between PROPFIND and 207 Multi Status is for me: 328.776 - 328.635 = 0.141 seconds

I am now looking again at my nginx setup, with the ssl reverse proxy on the server. I recently disabled sslv3 for the poodle attack, but the ssl tests on the Internet say that the website (https owncloud.pokorra.de) is configured fine.

ckamm commented 9 years ago

@tpokorra Thanks for testing! You're saying the 32bit client works fine if your server doesn't use SSL. Maybe there's some issue with a SSL library - or the way the client uses it - in 32 bit builds?

If your server works fine against a 64bit client its unlikely to be a server issue - can you try that?

tpokorra commented 9 years ago

@ckamm Yes, 32bit client 1.7.0 on Ubuntu 12.04 works fine if the server does not use SSL, but is in trouble if accessing the server over SSL.

I tried the 64bit client 1.7.0 on Ubuntu 12.04, and it works fine against the server using SSL.

ckamm commented 9 years ago

@tpokorra Good. So we seem to have an issue in the 32bit version of the SSL library, in Qt's use of it or in the client's use of Qt. And it's a complicated issue where the connection validator's PROPFIND succeeds (you do see a line "######## Connection and Credentials are ok!" in your log, right?) but the quota job's PROPFIND fails.

I'll look at the relevant code in the client. The chances of finding the bug like this are really low though. If you can give me any extra information (find a server SSL config that works, compile the client with different versions of Qt etc..) that'd be helpful.

ckamm commented 9 years ago

@stephane84 I've created owncloud/core#12744 to investigate the 'long running quota jobs' issue. Could you help people there in case they need more information about your specific setup?

tpokorra commented 9 years ago

@ckamm Thanks for looking into this!

Correct, Connection and Credentials are ok:

12-10 12:27:08:884 0x9ab5cc0 Connection Validator Result:  "Connected" 
12-10 12:27:08:884 0x9ab5cc0 ######## Connection and Credentials are ok! 
12-10 12:27:11:162 0x9ab5cc0 Folder in overallStatus Message:  Mirall::Folder(0x9c5cd80)  with name  "ownCloud" 
12-10 12:27:11:162 0x9ab5cc0 ######## connected to ownCloud Server! 
12-10 12:27:13:481 0x9ab5cc0 Folder in overallStatus Message:  Mirall::Folder(0x9c5cd80)  with name  "ownCloud" 
12-10 12:27:17:866 0x9ab5cc0 Folder in overallStatus Message:  Mirall::Folder(0x9c5cd80)  with name  "ownCloud" 
12-10 12:27:17:882 0x9ab5cc0 Mirall::CheckQuotaJob(0x9e535a8) Timeout 
12-10 12:27:17:882 0x9ab5cc0 void Mirall::AbstractNetworkJob::slotFinished() 5 "Operation abgebrochen" 
12-10 12:27:18:698 0x9ab5cc0 Client is on latest version!

It works with the nightly build of 32bit client 1.6.1 from http://download.opensuse.org/repositories/isv:/ownCloud:/community:/nightly/xUbuntu_12.04/

And it works with the 32 bit client 1.7.0 on Ubuntu 14.04

ckamm commented 9 years ago

@tpokorra To summarize:

32bit 1.6.1 Ubuntu 12.04: ok
32bit 1.7.0 Ubuntu 12.04: fail, but works on servers without SSL
64bit 1.7.0 Ubuntu 12.04: ok
32bit 1.7.0 Ubuntu 14.04: ok

And these (particularly 32bit 1.7.0 on Ubuntu 12.04 vs 14.04) were different packages? If so, looking at the difference between the 12.04 and 14.04 32bit 1.7.0 package could help.

ckamm commented 9 years ago

@hjrgit Could you check whether your issue is similar to what tpokorra reports? If it works without SSL or with a 32bit client on 14.04 I'd expect it to be the same issue.

If it's not a third thing, we'd have boiled this issue down to:

slow quota requests ('solved' by increasing timeouts, people on the server side are investigating)
a ssl-related bug that affects the 32bit 1.7.0 Ubuntu 12.04 package and isn't related to oC client code

hjrgit commented 9 years ago

sorry for delay. I have disabled SSL for testing temporary now. On client-side I have just changed the URL in owncloud.cfg from https to http

nothing more. AND: everything seems to work fine without SSL.

By the way: as mentioned at the beginning, we are using Xubuntu LTS 14.04

On Wed, 10 Dec 2014, ckamm wrote:

@hjrgit Could you check whether your issue is similar to what tpokorra reports? If it works without SSL or with a 32bit client on 14.04 I'd expect it to be the same issue.

If it's not a third thing, we'd have boiled this issue down to:

slow quota requests ('solved' by increasing timeouts, people on the server side are investigating)

a ssl-related bug that affects the 32bit 1.7.0 Ubuntu 12.04 package and isn't related to oC client code

Reply to this email directly or view it on GitHub: https://github.com/owncloud/client/issues/2485#issuecomment-66447111

hjrgit commented 9 years ago

@ckamm I have to add my experiences

64bit 1.7.0 Xubuntu 14.04: ok 32bit 1.7.0 Xubuntu 14.04: fail (works without SSL)

We have four 64bit systems and three 32bit systems - the result is on all systems the same: 64bit OK, 32bit not

But: we are using Xubuntu (XFCE) and not standard-Ubuntu; Unity or gnome is to much for our little 32bit-netbooks ;-) I don't know if this makes a relevant difference.

On Wed, 10 Dec 2014, ckamm wrote:

@tpokorra To summarize:

32bit 1.6.1 Ubuntu 12.04: ok

32bit 1.7.0 Ubuntu 12.04: fail, but works on servers without SSL

64bit 1.7.0 Ubuntu 12.04: ok

32bit 1.7.0 Ubuntu 14.04: ok

And these (particularly 32bit 1.7.0 on Ubuntu 12.04 vs 14.04) were different packages? If so, looking at the difference between the 12.04 and 14.04 32bit 1.7.0 package could help.

Reply to this email directly or view it on GitHub: https://github.com/owncloud/client/issues/2485#issuecomment-66444788

ckamm commented 9 years ago

@hjrgit @tpokorra Okay. Could you give me links to the exact packages you are using? Also, could you paste the version strings the client logs during startup, they look like this:

=====Using Qt 5.2.1 
=====Using SSL library version OpenSSL 1.0.1f 6 Jan 2014 
=====Using neon 0.30.0: Library build, IPv6, libxml 2.9.1, zlib 1.2.8, OpenSSL 1.0.1e 11 Feb 2013.

@hjrgit: for the 64bit and 32bit 14.04 version (I don't think you use 12.04 at all?) @tpokorra: for the 32bit version on 12.04 and 14.04 (64bit can't hurt either). Could you also double check that 14.04 32bit really works?

Maybe we can find a version difference that lines up with what works and what doesn't.

hjrgit commented 9 years ago

I'm using the packages from this repository: http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/xUbuntu_14.04/

At one of the 32bit systems I've tried http://download.opensuse.org/repositories/isv:/ownCloud:/community:/nightly/xUbuntu_14.04/

I will post the mentioned log strings today in the evening as soon as I'm back in the office.

On Thu, 11 Dec 2014, ckamm wrote:

@hjrgit @tpokorra Okay. Could you give me links to the exact packages you are using? Also, could you paste the version strings the client logs during startup, they look like this:

=====Using Qt 5.2.1 =====Using SSL library version OpenSSL 1.0.1f 6 Jan 2014 =====Using neon 0.30.0: Library build, IPv6, libxml 2.9.1, zlib 1.2.8, OpenSSL 1.0.1e 11 Feb 2013.

@hjrgit: for the 64bit and 32bit 14.04 version (I don't think you use 12.04 at all?) @tpokorra: for the 32bit version on 12.04 and 14.04 (64bit can't hurt either). Could you also double check that 14.04 32bit really works?

Maybe we can find a version difference that lines up with what works and what doesn't.

Reply to this email directly or view it on GitHub: https://github.com/owncloud/client/issues/2485#issuecomment-66586645

tpokorra commented 9 years ago

I did now a clean installation of Ubuntu 14.04 and Ubuntu 12.04, both 32bit, and owncloud client works on both, against my owncloud server over ssl.

I have compared the installed dep packages, of qt and ssl, and they look the same to the Ubuntu 12.04 32bit machine where it does not work.

I cannot see the strings about the ssl and qt version in the logfile, nor in the logwindow. I am now in the process of building the owncloud client from git, will see if that shows more details.

ckamm commented 9 years ago

@tpokorra You are saying the client works fine on a different machine with seemingly the same dependencies?

You can get the version info by starting like this:

bin/owncloud --logfile - | grep 'Using Qt' -A 2

tpokorra commented 9 years ago

ok, with the build from git master, it works on my machine, where 1.7.0 did not work before.

I get this output:

12-11 10:51:45:190 0x8fb9cc0 =====Using Qt 4.8.1
12-11 10:51:45:190 0x8fb9cc0 =====Using neon 0.29.6: Library build, IPv6, libxml 2.7.8, zlib 1.2.3.4, OpenSSL 1.0.1 14 Mar 2012.

The quota also displays fine in the client.

I think, for me this is fine, with the next release of the owncloud client I should be fine on my 32 bit Ubuntu 12.04 and 14.04.

ckamm commented 9 years ago

@tpokorra So are the version stings different between the version you built and the package that didn't work? Could you build the v1.7.0 tag and check whether that works? That's precisely what 1.7.0 was built from.

tpokorra commented 9 years ago

@ckamm I have built now the v1.7.0 tag, and it shows the same broken behaviour. Unfortunately, the "Using Qt" and "Using neon" output was not part of v1.7.0 yet, I checked src/libsync/syncengine.cpp, but that does not exist in v1.7.0. So I added the debug code from https://github.com/owncloud/client/blob/master/src/libsync/syncengine.cpp#L566 to src/mirall/syncengine.cpp.

Now I get for my own built v1.7.0:

12-11 12:10:29:823 0x98f8cc0 =====Using Qt 4.8.1 
12-11 12:10:29:825 0x98f8cc0 =====Using neon 0.29.6: Library build, IPv6, libxml 2.7.8, zlib 1.2.3.4, OpenSSL 1.0.1 14 Mar 2012.

Not surprisingly, that is the same as for the build from master.

I tried to apply your fix about the quota https://github.com/owncloud/client/commit/d8c59fcb7397493a0471355732068909afc1c332 to my v1.7.0 checkout, but the code has changed a lot, so it would not apply easily. But I suspect that your commit fixed my problems.

ckamm commented 9 years ago

@tpokorra Okay, I'm glad to hear your problem is solved in the 1.7 branch! Thank you for all the testing.

ckamm commented 9 years ago

@hjrgit Since the problem went away for @tpokorra with a newer build, could I ask you to try a recent daily build again? https://software.opensuse.org/download/package?project=isv:ownCloud:community:nightly&package=owncloud-client

Please also provide an updated log, filtered through (if necessary)

grep -i 'using\|folder\|sync finished\|start syncing\|timeout\|quota'

Even if the 'no sync' part of the problem persists, we should see the quota job take 5 minutes to time out. And that should help with the '100% CPU' part of the issue.

owncloud / client

[Linux] [1.7.0] 100%CPU - no sync #2485