** Description changed:
+ SRU justification : Race condition exist when two instances of duplicity run
in the same
+ cache directory (.cache/duplicity)
+
+ Impact : Potential corruption of the local cache
+
+ Fix : Add a lockfile in the local cache & prevent execution of a second
instance in the
+ case of the presence of the lockfile
+
+ Test Case :
+ 1) Run one instance of duplicity :
+ $ sudo mkdir /tmp/backup
+ $ sudo duplicity --exclude=/proc --exclude=/sys --exclude=/tmp /
file:///tmp/backup
+
+ While this command is running execute the following in a separate console :
+ $ sudo duplicity collection-status file:///tmp/backup
+
+ With the new locking mechanism you will see the following :
+ $ sudo duplicity collection-status file:///tmp/backup
+ Another instance is already running with this archive directory
+
+ To disable the locking mechanism, the --allow-concurrency option can be used :
+ $ sudo duplicity --allow-concurrency collection-status file:///tmp/backup
+ Local and Remote metadata are synchronized, no sync needed.
+ Last full backup date: Mon Jan 20 17:11:39 2014
+ Collection Status
+ -----------------
+ Connecting with backend: LocalBackend
+ Archive dir: /home/ubuntu/.cache/duplicity/ba8d32ccb88d13597b4784252744fc75
+
+ Found 0 secondary backup chains.
+
+ Found primary backup chain with matching signature chain:
+ -------------------------
+ Chain start time: Mon Jan 20 17:11:39 2014
+ Chain end time: Mon Jan 20 17:11:39 2014
+ Number of contained backup sets: 1
+ Total number of contained volumes: 3
+ Type of backup set: Time: Num volumes:
+ Full Mon Jan 20 17:11:39 2014 3
+ -------------------------
+ No orphaned or incomplete backup sets found.
+
+ Regression : In the case of spurrious interruption of duplicity, the lockfile
+ will remain in .cache/duplicity which can prevent future use of duplicity.
The cache
+ directory will have to be cleaned or the --allow-concurrency option will be
needed
+
+ Original description of the problem :
+
When runnining "duply X status" while running "duply X backup" (sorry, I
don't know which duplicity commands are created by duply) due to a race-
condition the code of 'sync_archive' might happend to append newly
created meta-data files to 'local_spurious' and subsequently delete
them. This delete seems to have been the reason that triggered bug
1216921.
The race condition is that the backup command constantly creates meta-
data files while the status command queries the list of local and remote
files independently over a larger time span. This means that a local
file might already been remote but the status command did not see it a
few seconds ago.
** Changed in: duplicity (Ubuntu Quantal)
Status: Triaged => In Progress
** Changed in: duplicity (Ubuntu Raring)
Status: Triaged => In Progress
** Changed in: duplicity (Ubuntu Saucy)
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1266763
Title:
Race condition between status and backup
To manage notifications about this bug go to:
https://bugs.launchpad.net/duplicity/+bug/1266763/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
