Please describe what you are doing to trigger the bug:
My connection isn’t the best and certain ssh connections will drop from time to time (but not all ssh connections always drop at the same time). When this happens, duplicacy doesn’t clean up old ssh threads before spawning new ones.
This is with duplicacy 3.2.5 running on Debian Linux.
Repro steps:
On client, run duplicacy backup with threads=4.
On server, manually kill one of the 4 sshd processes.
Please describe what you expect to happen (but doesn’t):
Expect duplicacy to close the remaining 3 ssh connections before starting 4 new ones.
Please describe what actually happens (the wrong behaviour):
The 3 existing sshd processes remain on the server and 4 new ones are started, resulting in a total of 7 processes. If you kill one of the 4 new sshd processes, then 6 existing ones remain and 4 new ones are started, resulting in 10 sshd processes. And so on and so on…
For a long-running initial backup with several ssh connection drops, this results in an ever-growing number of sshd processes eventually exhausting all the resources on my sever.