If you plan to leave
--log-file running even after this is resolved, consider setting up a
--run-script-after parameter to rename / cleanup the log files.
If you’re using something like
--log-file-log-level=profiling the logs can get pretty big pretty quickly…
Also, are you using any additional parameters (like
--webservice-interface) that might make Duplicati slow to start?
@ts678, thanks for the link to the GitHub issue. Assuming I understood it correctly, you “recently” posted that you think this timeout might be due to verifying updates before trying to start the most recent one.
Have you tested reducing the number of older versions in the
updates folder or even doing a “base version” install of your currently running update version?
@kenkendk, if a user is running an older base version (let’s say 126.96.36.199 canary) and has a bunch of versions in the updates folder (say 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, and 22.214.171.124) and they choose to do a new base version installation (say an MSI for 126.96.36.199) what happens to the updates folder?
Do older versions get purged or ignored at startup or are we still getting the hit of verifying “updates” that are older than the base version?