From: edgar . soldin
Date: Thu, 14 May 2020 11:42:37 +0200
> On 14.05.2020 08:37, Diagon via Duplicity-talk wrote:
> > I'm running duplicity with cron and a command like this:
> > PASSPHRASE="mypassword" flock -n /tmp/backuplock /usr/bin/duplicity
> > --log-file /home/me/duplicity.log --backend-retry-delay 60
> > --asynchronous-upload --name TEST --volsize 50 --full-if-older-than 6M
> > --exclude '**.lock' /home/me/Desktop/TEST sftp://address@hidden/Backup
> duplicity uses it's own locking based on the backup target. any specific reason
> why you added your own?
Ah, I didn't realize. I guess that'll work. I'm running a backup of a critical directory every 20 minutes. If it does a full backup, rather than incremental, it could take 2 hours. I need to make sure they processes don't pile on top of each other.
> > The network has gone down and come back up, but duplicity neither continues
> > nor terminates. As a result the lock (flock) is not relinquished, and so
> > cron is unable to start a new task to finish what was incomplete.
> > Anyone have thoughts on a way to solve this?
> find out if duplicity is in fact still running. check the log. what does it say?
Definitely running, as per `ps ux | grep duplicity`
> default number of retries is 5 times your 60 seconds, so it'll will wait at
> least that long.
I waited a couple of hours.
> if you cannot figure out what is going on, kill duplicity, rerun it with max
> verbosity (-v9), up/down network again and see if you can reproduce it.