Startup Logs? / Duplicati won't start

Hello all

Do startup logs exist somewhere that isn’t the DB? I’m trying to debug why Duplicati won’t start.

Extended explanation

I had Duplicati 2.0.4.23 installed as a Window service (Windows 10-1803) and it worked just fine. I also have Duplicati installed on numerous other Windows computers.

They all, one by one, upgraded to 1803/1903 releases of Windows 10 and I lost configs in the infamous “1803 removes the Windows directory” issue.

As such, I wanted to change the install directory (Migrating from User to Service install on Windows) locally. I didn’t realize it wasn’t just a change of data directory, so I uninstalled the service first.

I had a 2nd thought and decided to do this later, and reinstalled the service without specifying data directory and Duplicati wouldn’t start. Watching Task Manager, the Duplicati.WindowsService.exe is running without issue. Meanwhile, Duplicati.Server.exe is changing PID roughly 2-4 times a second. Something isn’t working, but I don’t see any error printouts and the only place I’ve seen the system log has been in a running Duplicati instance, so I’m unsure how to debug the service not starting up.

Everything I did:

  1. Stop running Duplicati service
  2. Duplicati.WindowsService.exe uninstall
  3. “User Decide against doing this now”
  4. Duplicati.WindowsService.exe install
  5. sc start Duplicati
  6. “Duplicati isn’t starting and the service keeps restarting… where are the logs?”

Welcome to the forum @rcmaniac25

If a program goes down early enough, it sometimes leaves a Duplicati-crashlog.txt around. One I have is:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Duplicati.Server.SingleInstance+MultipleInstanceException: Another instance is running, and was notified
   at Duplicati.Server.Program.RealMain(String[] _args)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at Duplicati.Library.AutoUpdater.UpdaterManager.RunMethod(MethodInfo method, String[] args)

and it was in my updates folder. Possibly your service would use C:\ProgramData\Duplicati\updates.

The above is also a reminder to make sure there aren’t any extraneous Duplicati processes still running…

If the crash (or exit for whatever reason) is later, you might be able to get a –log-file option on the Server by Duplicati.WindowsService.exe passing them on as below (or just add desired options with services.msc):

It is possible to pass arguments to Duplicati.Server.exe , simply add them to the commandline

Another test you can try just to see if somehow Duplicati.Server.exe won’t start for anyone, you can make sure Task Manager shows no Duplicati processes of any sort, and then progressively start the server, e.g.

Duplicati.Server.exe help running will show at least that much ran, then you can actually do a normal start without any extra options. It should start with no backups (unless you created some once as non-service), but at least you’ll have some confidence that the server can start in at least the case of an interactive user.

Thanks for the welcome @ts678, I don’t know why I didn’t make an account sooner.

So, I confirmed nothing else is running.

I don’t have the crashlog in the updates folder.

I added a log file through Duplicati.WindowsService, and when I start the service, the log file is created… but the file is empty. It never contains even a newline.

Last thing I tried was running Duplicati.Server directly (no arguments), and it did start successfully.

So direct invocation works, but through the service it didn’t. One note (I don’t know if this is correct or not), when I start the service, I see 2 Duplicati.WindowsServer instances, and then 1 Duplicati.Server instance (that keeps restarting).

So seemingly the program is intact. I don’t know why environment makes so much difference. Easiest test might be to isolate by using services.msc to have it run as a service as your user (not SYSTEM). Seeing that run implicates the user rather than the service environment. Running interactively as SYSTEM can be done with Microsoft Sysinternals PsExec with the -i and -s options to get a cmd.exe to hand-run Duplicati. Possibly some error message will show up on the screen. Alternatively you can use Process Monitor to try guessing what went wrong from the activities before its exit – but this requires more expertise to interpret.

Duplicati processes often come in pairs, with the first starting from C:\Program Files\ Duplicati 2 which then checks for any installed updates and starts a child from updated code. This is very easily seen with Sysinternals Process Explorer, for example by hovering over the process name in the Process column. Without an installed update, the child also runs from Program Files. I don’t know which situation you got.

I hope that’s a typo for WindowsService. The child should start the Server which doesn’t go looking for an update because it knows WindowsService did that already. But it should not die (and then be restarted)…

I suppose you could also try making sure your SYSTEM database is still good, e.g. by copying Duplicati-server.sqlite to your personal Duplicati area in %LOCALAPPDATA%\Duplicati to see if server will read it. Don’t actually run anything (and this includes scheduled jobs if you have any) or it might make a mess…

I’m not sure what changed on your system that might have caused this. Did you retrieve your old configs before they aged away? If not, probably best to do that now. Still, I wouldn’t “think” no config stops a start.

@ts678 Oops, yes… I typoed and Duplicati.WindowsServer should’ve been Duplicati.WindowsService.

So PsExec may have found the issue.

I did a couple tries and every time the same thing happened:

  • Duplicati.Server (keeps restarting without error print out or log)
  • Duplicati.WindowsService (matches the PID of the Windows Service)
  • Duplicati.WindowsService (not sure what this one is, but you seem to indicate it’s the updater)

I tried running the service as myself and… it started. Ok, so it only happens when run under SYSTEM. So then why is… wait. Why does it say Duplicati 2.0.3.3 beta? Before I did my original “Duplicati.WindowsService uninstall”, I had 2.0.4.23 installed and running… my updates folder even has that still there.

“Maybe I should uninstall/reinstall Duplicati itself to make sure I’m on the latest beta version”

I then decided to run PsExec. A window for Duplicati.Server popped up and…

A serious error occurred in Duplicati: System. Exception: Failed to create, open or upgrade the database.
Error message:
The database has version 6 but the largest supported version is 4.

This is likely caused by upgrading to a newer version and then downgrading.
If this is the case, there is likely a backup file of the previous database version in the folder C:\WINDOWS\system32\config\systemprofile\AppData\Local\Duplicati.
at Duplicati.Server.Program.GetDatabaseCOnnection(Dictionary`2 command;ineOptions)
at Duplicati.Servier.Program.RealMain(String _args)

Please note I copied that from a screenshot since the window closed before I could copy the text.

My databases are still there, and I have a backup of the (encrypted) config files in case I ever need to re-create my setup.

I’ll wait for your reply before I go and do anything, in case more info is desired, but I repeat and extend what my steps were originally (first post):

  1. Stop running Duplicati service (2.0.4.23)
  2. Duplicati.WindowsService.exe uninstall
  3. “User Decide against doing this now”
  4. Duplicati.WindowsService.exe install
  5. sc start Duplicati
  6. “Duplicati isn’t starting and the service keeps restarting… where are the logs?”
  7. Talk on forums and double check server
  8. Find out Duplicati is now 2.0.3.3
  9. Wait for reply <-- now
  10. Re-install Duplicati to make sure any old binaries are no longer there

Do you still have the Windows.old folder? I’m wondering if there might be a 2.0.4.x update left behind.
C:\ProgramData\Duplicati\updates is said to be the usual spot. Is a 2.0.4.x there (or anywhere)?

Version 4 would be consistent with with 2.0.3.3, so the trick is getting 2.0.4.5 or nearly-same 2.0.4.23, probably from .msi install. Probably best to remove any 2.0.4.5 or 2.0.4.23 update folders you see, or debugging and code study might be possible if you see any, and think 2.0.3.3 should have seen them. Sometimes bugs do get fixed. You can also confirm with Process Explorer that the WindowsService detection-of-updates didn’t put its child on the update. Process Monitor can show where it had looked.

I don’t have the Windows.old folders on any computer anymore. The computer I’m currently on and brought up the service issue for still has the DBs from 2.0.4.x.

I’ll check what’s getting started to make sure it’s the right one. Might re-install if it’s not functioning.

Ok, it’s been much too long (without a backup). I made a copy of my DBs then deleted the folder, removed the update folders, ran the service (which started), ran the updater to get back to 2.0.4.23, stopped the service, restored my DBs, started the service and everything is back to normal. I will go back my original goal of moving the DBs from the systemprofile to a proper storage location.

Thanks for the help! (I’ll mark your response as solution as it did point in the direction to go)