I have a backup that I ported over from a Linux host to a Windows host (exported JSON configuration, reimported into Windows, then edited dlist files to match new source paths).
I found that if I try to run the database repair or the backup through the web UI, it starts but after a little bit of network activity contacting my backend (OneDrive), the activity stops and the progress bar still shows 0 progress (e.g. Verifying backend data). At that point, there is zero disk activity, no CPU use, and no network activity from the Duplicati processes (running as a service).
In an attempt to see if there was more feedback about what might be going wrong I decided to run those actions directly through the Duplicati.CommandLine.exe program, and to my surprise, everything worked.
When rebuilding the database, it contacted the backend and downloaded a bunch of files, finally rebuilding a new SQLite database.
When running the backup, it contacted the backend and then started a whole lot of disk and CPU activity, examining all the files on my source, before finally uploading changes successfully.
The backup command I ran was obtained using the Export feature from the web interface and choosing the Command line option. I ran it as the local system account, which is what my service is running as (default settings).
Are actions initiated from the web UI very different than those being run by the command line program? How can I fix my front-end so that I can control the back-ups from there instead of having to use the command line tool?
I had left a backup “running” today that was initiated through the web interface and there was no progress at all (again, zero CPU and disk activity). Eventually I decided to stop the Windows service and interestingly, the exact moment I stopped the service, the backup started running. There is now a bunch of disk and network activity (connecting to my backend provider) and the progress bar in the web UI started moving. After a while, the Duplicati Server process exited and when I restarted the service, it looks like the back-up completed successfully.
So it seems that something about triggering the shutdown/service stop sequence will allow the back-up to become unstuck.
I might try to load up the debug version and take a stab at seeing if I can figure out where it’s becoming stuck/unstuck… so strange, I never saw this before when I was running Duplicati on Linux.
So this is interesting, I appear to be observing the code getting stuck on a Console.WriteLine statement in the OneDrive.cs backend class (line 279 on release/2.0.3.3_beta branch). I’ve seen it become unstuck eventually once or twice, but as I’m typing now, it’s hung again on the WriteLine. Seems like the underlying stream is blocked or something?
I can tell it’s stuck there because when I break into the debugger while the process appears to be hung, I switch between the threads until I find the thread in OneDrive.cs. It’s on the Console.WriteLine and if I set any breakpoints after it, they are never hit when resuming. Pausing again, it’s still on that line and the local variables haven’t changed (namely the offset counter is stuck at the same value).
And of course per my observations earlier, if I stop the Duplicati service, the Console.WriteLine call that was blocked returns and the backup continues along successfully.
To verify if this is an issue or not, perhaps I’ll rebuild a version with this statement commented out.
I’ve done a lot of .NET code before, and I’m not recalling a time that I’ve seen a Console.WriteLine statement block seemingly indefinitely?
Not sure if it’s an environment issue on my machine or something else…
No, they are the same. The web-ui and commandline calls the same library methods.
I think this has to do with the setup. The webserver runs from the commandline, but it is wrapped with an updater that relays stdout from the spawned process.
My guess is that at some point the main process can no longer send data to stdout, and then all attempts to write are blocking.
The line in OneDrive.cs should not be there because it is a debug statement. I have just comitted a fix that removes this line and others like it.
BTW: Microsoft is discontinuing the API used in the OneDrive backend, so you should migrate to the OneDriveV2 backend.