Windows - Duplicati service dont start tasks at all

1

Hello,

I have the following issue using with Duplicati service and tasks that don’t start as scheduled with the service usage.

Context :

  • Fresh install of Windows Server 2022 standard
  • Default install of up to date Duplicati 2 (2.0.8.1)
  • All settings are done from the domain’s administrator account

I setup a file backup task from local files to a OneDrive V2 destination using the systray icon/web GUI. Snapshot policy is : required, http-timeout : 10 minutes

The task starts and completes well when started from this web GUI, no issue here.

I then realized the default install does not register and use a service and so doesn’t run scheduled task if not open. The admin user session being closed after every usage, the following planned execution didn’t start.

So I then installed the service with the simple command in the documentation :
Duplicati.WindowsService.exe install. So it is run by SYSTEM account, as intended.

The service registered nicely, and started. Il also starts successfully on a system reboot. The process Duplicati.Service is loaded, using ~18MB of RAM.

The scheduled tasks doesn’t start at all when it should**. No set up email log is sent, in contrast to manually or GUI-started task.

When connecting to the web GUI, the tasks then immediately start because its schedule is overdue, and the log clearly shows the task wasn’t started (no log entries) as it should and only manual or planned launches from the GUI are listed.

What could be wrong ? Might the process instance run by the service be using a different jobs set than the Duplicati GUI process ?

Thanks.

2

Okay, my assumption was right : the service listen on port 8200 with its own job set, while the first instance (GUI) uses port 8300.

Upon connecting with a browser on the instance on port 8200, I saw it was brand new and not set up. I exported the task settings from the 8300’s to the 8200’s and waiting for it to run now.

3

Duplicati general settings had to be set up again, also (settings for logs emails, http timeout and snapshop policy were also empty)

Had to do a database repair because the remote file were not listed, but the task completed cleanly afterwards. Email log was sent.

4

Thoughts : to prevent this predictable issue, the Windows Installer should offer to register the service right from the installation and the link from the tray icon should then target the port 8200 accordingly.

I believe this would prevent confusion of setup context between classic user app and service running.

5

Hi @Felger, good to hear that you figured it out.

There is another thread that explains how to set up the TrayIcon to connect to the service:

My plan for this is to offer the “Install as service” option in the MSI, and then configure it to work during the installation. I have not prioritized it yet, because I want to get the web-server out of the service first, so you do not have to run the webserver with elevated privileges.

6

If you still have old Duplicati job using the same destination as the service, be sure not to run it. Safer would be to never have the same destination used by any two jobs. They’ll get confused.

Migrating from User to Service install on Windows are current directions for doing what you did, however it’s pretty cumbersome compared to starting with a service from scratch. Request was:

and it’s old, but development resources have always been a limitation. Good to see a plan.

One further warning I’ll pass on from v3 of the migration directions linked above is this one:

  • v3 - solves the windows update/upgrade problem of deleting C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati