** 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 :
+ Test Case :
1) Run one instance of duplicity :
- $ sudo mkdir /tmp/backup
- $ sudo duplicity --exclude=/proc --exclude=/sys --exclude=/tmp /
file:///tmp/backup
+ $ 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
+ $ 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.
+ If you are sure that this is the only instance running you may delete
+ the following lockfile and run the command again :
+ /home/ubuntu/.cache/duplicity/3fe07cc0f71075f95f411fb55ec60120/lockfile
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
+ directory will have to be cleaned as outlined in the error message
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.
--
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
