How to cancel a job / task started from the command line?

Support
1

I’m interested in stopping a long running command from the command line exe, e.g. a compare command.

if you run:
Duplicati.CommandLine.exe compare file://dummy 1 0 --dbpath="path" --full-result

and then a second or so after running, hit Ctrl+C to stop it, the command appears to stop immediately, and you return to the terminal prompt.
however, if you watch the task manager, you can see that a Duplicati.CommandLine.exe instance keeps running, using up resources, until it eventually goes away.

it seems like the command line just delegates a command to another process, which then runs the command regardless of if you stopped it or not.

thus, my question is: what is the safest/intended way to (actually) stop an ongoing command line process like this?

i’m not sure if killing the running Duplicati.CommandLine.exe process is a good idea, as i’ve tried it before and it seems to cause locking issues.

but please, let me know how i should be stopping it. is there something like a command i can pass it to make the background process stop?, etc

2

Welcome to the forum @starwarswii

Both the command line and the server (web UI) Duplicati delegate to another process running the latest update. This avoids needing Administrator privileges, which is a good thing to some (and bad to others).

If you’re happy doing updates via .msi install rather than Duplicati’s system, you can get single-process:

set AUTOUPDATER_Duplicati_SKIP_UPDATE=true

and possibly that will let the Duplicati that does the work be the one that gets killed. I’d caution that killing Duplicati while it’s busy can lead to database corruption. The GUI has only recently gotten better at Stop operations (even in latest Beta “Stop now” is less safe than “Stop after current file”). The CLI lacks these.

An enhancement request could be put in forum Features category or GitHub issues to get it in the queue, however there’s a big backlog, and figuring out a way to get directives to another process may be difficult.

Console.CancelKeyPress Event might be a way to catch the Ctrl-C if someone coded just that capability.

Although it’s also not simple, a better approach might be to make Duplicati safe when killed at any time… Systems go down (power fail, restart, OS crash, etc.), and ideally Duplicati should put up with that safely.

Hard-killing a compare is probably safe, but I’d be nervous about doing it on a backup, as you’ve noticed.

None I can think of. Duplicati programs are kind of standalone, e.g. server and each CLI are independent.
Third-party program duplicati-client is an attempt to give CLI access to the server for those who want it…

3

thanks for the info. all very useful.

when first downloading duplicati, i honestly thought this was one of it’s main selling points. seems i read too much into the network-resilience talk, and assumed the whole product was like that.
i think making duplicati idiot-proof (can be killed whenever, restarted, etc) is really important and should be focused on. that’s a really good feature for a backup system to have: that you have no chance of screwing up your backup

4

I don’t think you’ll find any disagreement that this is important, but keep in mind you have an unfinished beta product. How robust it needs to be before it’s called stable has been the topic of discussion and requires a substantial amount of effort which is difficult to achieve when all the available volunteers are fully occupied.

Other really important things include: it should install, should not fail by itself, should not fail from a network error, should restore, etc. All of those have had either general hard-to-find issues or unusual cases solved, however some are fixed only in Canary which is rather bleeding-edge. At some point, a Beta will come out.

For awhile the “focus” (a word I’m not fond of unless somebody says what not to do) was on doing 2.0.5.1, which had a lot of reliability fixes in it. That was 14 months after the prior Beta, and I hope we can do better.

is one statement of the situation. It’s sometimes very hard to figure out how to break things, especially in a way that allows a fix to be done. What would be ideal would be more volunteers to do negative testing with enough control and logging to allow the developers to understand what’s going on and to resolve the issue.

Early on, user reported problems are easy to reproduce, so easy to fix. This is less and less the case now.

If you believe this is really important enough that you will help, there are probably various holes to be found. They’re not all huge holes. I just killed my Duplicati process three times in mid-backup, and got no failures, in fact the recovery on next backup did what it should, and marked the backup as partial, and uploaded the synthetic filelist which is the previous backup list plus updates completed before the interruption was done.

So in that case the design worked as intended (and I think that’s one of those Canary fixes not yet in Beta). Things gets progressively harder as the problems get harder to reproduce. Even SQLite has its limitations and so does hardware. I’ve seen data sheets of current disk drives that won’t guarantee data integrity if the prescribed shutdown sequence from the OS isn’t followed. Good luck with that during crash or power loss.

Best practice with backups is always to have multiple backups, done differently, in the hope that misfortune doesn’t hit both at the same time. Software is never completely perfect, and that includes backup software.

EDIT 1:

While I would be thrilled if you test carefully and submit quality reports, you can also just try doing what you originally wanted to do and see how well it holds up. Surprisingly, I can’t find any prior discussions quite like what you wanted. I think most users use the GUI, and fixes are generally driven by the issues the users file.

EDIT 2:

I didn’t focus on this in my earlier research for kill issues, and I know there have been some mysterious locking issues (possibly related to the incomplete kill that you saw – similar issue happens on GUI Quit). Please feel free to file a GitHub issue with steps so anyone to reproduce it. That’s the key to getting a fix.