When the xfce desktop is locked, you would expect the client to resume sync
Owncloud desktop client pauses syncing
Operating system:
Debian 9
Web server:
Database: n/a
PHP version:
ownCloud version: Latest stable
Storage backend (external storage): n/a
Client version: latest clone of master (1 week ago)
Operating system: Debian 9
OS language: English
Client package (From ownCloud or distro) (Linux only): owncloud
@poetsmeniet That's weird. Does your desktop disconnect the network when you log out? Maybe enable logging (https://doc.owncloud.org/desktop/2.5/troubleshooting.html#obtaining-the-client-log-file) and check out what the log says during the time you're logged out.
Hi,
I have the same Problem! Owncloud client is installed on Windows Server 2016 and should sync with Server "Hosted Server"! It works fine but just when I log in.
:(
@farhadtorkany Win Server 2016 is very different from Debian 9. Please don't use this issue to discuss the Win issue.
@ckamm I checked the logging and it seems the client is being locked.. during one minute logout there was an approximate one minute gap in the log
Interesting! I guess the process is paused? We'll need to investigate what the right way to avoid that behavior is.
@poetsmeniet Which lock screen are you using? light-locker?
No, I'm pretty sure it's the default locking of xfce4. But strangely enough it also happens when I got to virtual console (alt-ctrl-F1) where I am running tcptrack on the nic. Going back to F8 (window manager) the client starts syncing again
@poetsmeniet That's really odd, I don't know what would cause that. Could you test whether other gui programs behave the same? If it's not something external sleeping these processes, we probably need someone to attach a debugger and check what makes the program lock up.
FYI I know this feature only from macOS/iOS
https://www.howtogeek.com/277414/what-is-app-nap-is-it-slowing-down-my-mac-apps/
I observe this behaviour too. For example, last night I left ownCloud desktop client running on my work (Xfce) desktop with the screen locked as I was leaving to go home, at around 6PM. Later at home at around 8:15PM I added a few hundred MB of files to my dedicated home ownCloud server (which uses my home ADSL connection with a slow uplink so takes many hours to have my work machine sync). My home desktop (also Xfce) synced instantly since at that point the files were transferred over my home LAN, so I switched my desktop off and went to bed.
Then today when I got into work and logged into my desktop at around 9:15AM. Looking through the ownCloud logs I see that files were syncing last night from around 8:15PM up until around 10:30PM, and then simply stopped. They had resumed from around 9:15AM this morning - around the time I unlocked the machine.
I leave my work machine running so I can VPN into the office and SSH into it remotely, so there is nothing suspending it. Uptime on both server and desktop is at least 4 days. There's no reason ownCloud should stop syncing - but I consistently observe that it doesn't sync overnight. Locking the screen didn't instantly cause the client to stop syncing, but unlocking it did instantly resume it.
FWIW, I'm just running the Debian stable 2.2.4 ownCloud version, which is obviously a bit behind. Not sure if that matters. I'd rather stick to the Debian repos if possible.
@boltronics Thanks for the detailed report!
There's nothing in the client that would abort or pause syncing just because the user is logged out. I assume something must be going on externally.
Could you enable logging in the desktop client (https://doc.owncloud.org/desktop/2.5/troubleshooting.html#obtaining-the-client-log-file) and possibly share the log (mail at ckamm dot de)? Usually the client logs at least once per minute - if there are significantly longer gaps something probably paused the process.
Can you confirm that the network connection stays up overnight?
Currently we don't know what's causing this behavior or what we could do to avoid it.
Agreed. If it's only happening for Xfce users, there must be something an Xfce component does that's triggering this behaviour.
My home server also acts as my NAT gateway/router, and I can confirm the pppd logs have not logged anything since the machine was last booted, well over 2 weeks ago. It's very rare for the connection to drop, so this is expected.
I would also expect the Internet access at my workplace (which is close by) to be at least as reliable, but I don't have access to the router logs for that since the ISP provides the router. I do however have access to an external monitoring service that checks services we host on that connection every minute, and it did not log any errors. In the unlikely event that it did go down, it wouldn't have been for more than a few seconds.
Some additional info: Both home and office use a static IPv4 address. I use download speed limiting on the client (set to 35KBytes/s) to keep my home Internet connection usable while the client is receiving files.
Unfortunately my older version of ownCloud does not have the "Permanently save logs" button, so I relaunched it with the --logdir and --logexpire arguments. The next time I transfer enough data that I need to leave the client syncing overnight, I'll try to remember to check and update this and/or e-mail you the logs. Thanks.
Just an update to this. I finally upgraded my home server to ownCloud 10.2.0, and in doing that I needed to upgrade my client in order to continue connecting. Ultimately I ended up using the official upstream ownCloud hosted by the OpenSUSE Build Service repo, like so:
$ apt-cache policy owncloud-client
owncloud-client:
Installed: 2.5.4.11654+oc-515
Candidate: 2.5.4.11654+oc-515
Version table:
*** 2.5.4.11654+oc-515 100
100 http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Debian_9.0 Packages
100 /var/lib/dpkg/status
2.5.1.10973+dfsg-1 50
...
Last night I synced a new album from home (using the same client version), and I checked the logs and it actually synced without issue overnight to my work Xfce desktop, which (as usual) was locked.
So I'm still no closer to understanding the cause of the problem, but it seems that it's either fixed in later versions, or alternatively the bug is specific to the packages provided by Debian. Either way, I suppose this issue can now be closed if nobody else is still experiencing it.
@boltronics Thanks for the update, I'm sure to check after updating myself.. will close the issue
CC @hefee who maintains the debian packages on debian.org