| 2014-01-07 13:23:11 |
Kurt Huwig |
bug |
|
|
added bug |
| 2014-01-07 16:15:18 |
Reik Keutterling |
bug |
|
|
added subscriber Reik Keutterling |
| 2014-01-13 14:55:48 |
Kurt Huwig |
attachment added |
|
This patch adds a new command line parameter "--lockfile" that allows to define a lockfile which will prohibit parallel executions on the same host. https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3947671/+files/duplicity-locking.patch |
|
| 2014-01-14 09:20:56 |
Kurt Huwig |
attachment added |
|
adds option '--single-instance https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3948328/+files/1266763-locking-option.patch |
|
| 2014-01-14 09:32:59 |
Kurt Huwig |
attachment added |
|
adds option '--single-instance' and proper error message https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3948338/+files/1266763-locking-option.patch |
|
| 2014-01-14 09:36:28 |
Kurt Huwig |
attachment added |
|
1266763-locking-option.patch https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3948339/+files/1266763-locking-option.patch |
|
| 2014-01-14 10:40:36 |
Louis Bouchard |
bug |
|
|
added subscriber Louis Bouchard |
| 2014-01-15 12:08:32 |
Pierre Amadio |
bug |
|
|
added subscriber Pierre Amadio |
| 2014-01-15 17:04:08 |
Louis Bouchard |
duplicity: status |
New |
In Progress |
|
| 2014-01-15 17:04:11 |
Louis Bouchard |
duplicity: assignee |
|
Louis Bouchard (louis-bouchard) |
|
| 2014-01-17 16:57:08 |
Louis Bouchard |
bug task added |
|
duplicity (Ubuntu) |
|
| 2014-01-17 16:57:23 |
Louis Bouchard |
nominated for series |
|
Ubuntu Precise |
|
| 2014-01-17 16:57:23 |
Louis Bouchard |
nominated for series |
|
Ubuntu Trusty |
|
| 2014-01-17 16:57:31 |
Louis Bouchard |
duplicity (Ubuntu): status |
New |
In Progress |
|
| 2014-01-17 16:57:35 |
Louis Bouchard |
duplicity (Ubuntu): assignee |
|
Louis Bouchard (louis-bouchard) |
|
| 2014-01-17 17:02:58 |
Chris J Arges |
bug task added |
|
duplicity (Ubuntu Precise) |
|
| 2014-01-17 17:03:14 |
Chris J Arges |
bug task added |
|
duplicity (Ubuntu Trusty) |
|
| 2014-01-17 17:03:27 |
Chris J Arges |
duplicity (Ubuntu Precise): assignee |
|
Louis Bouchard (louis-bouchard) |
|
| 2014-01-17 17:03:31 |
Chris J Arges |
duplicity (Ubuntu Precise): status |
New |
In Progress |
|
| 2014-01-17 17:05:18 |
Chris J Arges |
nominated for series |
|
Ubuntu Quantal |
|
| 2014-01-17 17:05:18 |
Chris J Arges |
bug task added |
|
duplicity (Ubuntu Quantal) |
|
| 2014-01-17 17:05:18 |
Chris J Arges |
nominated for series |
|
Ubuntu Raring |
|
| 2014-01-17 17:05:18 |
Chris J Arges |
bug task added |
|
duplicity (Ubuntu Raring) |
|
| 2014-01-17 17:05:34 |
Chris J Arges |
nominated for series |
|
Ubuntu Saucy |
|
| 2014-01-17 17:05:34 |
Chris J Arges |
bug task added |
|
duplicity (Ubuntu Saucy) |
|
| 2014-01-17 20:22:58 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2014-01-17 20:23:06 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2014-01-17 22:06:47 |
Kenneth Loafman |
duplicity: importance |
Undecided |
Medium |
|
| 2014-01-17 22:06:47 |
Kenneth Loafman |
duplicity: status |
In Progress |
Fix Committed |
|
| 2014-01-17 22:06:47 |
Kenneth Loafman |
duplicity: milestone |
|
0.6.23 |
|
| 2014-01-17 22:06:47 |
Kenneth Loafman |
duplicity: assignee |
Louis Bouchard (louis-bouchard) |
|
|
| 2014-01-18 09:30:54 |
Louis Bouchard |
duplicity (Ubuntu Quantal): assignee |
|
Louis Bouchard (louis-bouchard) |
|
| 2014-01-18 09:30:57 |
Louis Bouchard |
duplicity (Ubuntu Raring): assignee |
|
Louis Bouchard (louis-bouchard) |
|
| 2014-01-18 09:30:58 |
Louis Bouchard |
duplicity (Ubuntu Saucy): assignee |
|
Louis Bouchard (louis-bouchard) |
|
| 2014-01-18 09:31:01 |
Louis Bouchard |
duplicity (Ubuntu Quantal): status |
New |
Triaged |
|
| 2014-01-18 09:31:04 |
Louis Bouchard |
duplicity (Ubuntu Raring): status |
New |
Triaged |
|
| 2014-01-18 09:31:08 |
Louis Bouchard |
duplicity (Ubuntu Saucy): status |
New |
Triaged |
|
| 2014-01-18 09:31:12 |
Louis Bouchard |
duplicity (Ubuntu Precise): importance |
Undecided |
Medium |
|
| 2014-01-18 09:31:15 |
Louis Bouchard |
duplicity (Ubuntu Quantal): importance |
Undecided |
Medium |
|
| 2014-01-18 09:31:17 |
Louis Bouchard |
duplicity (Ubuntu Raring): importance |
Undecided |
Medium |
|
| 2014-01-18 09:31:19 |
Louis Bouchard |
duplicity (Ubuntu Saucy): importance |
Undecided |
Medium |
|
| 2014-01-18 09:31:22 |
Louis Bouchard |
duplicity (Ubuntu Trusty): importance |
Undecided |
Medium |
|
| 2014-01-20 13:27:22 |
Launchpad Janitor |
branch linked |
|
lp:~louis-bouchard/ubuntu/precise/duplicity/fix-s3-and-add-locking |
|
| 2014-01-20 14:23:07 |
Launchpad Janitor |
branch linked |
|
lp:~louis-bouchard/ubuntu/trusty/duplicity/fix-s3-and-add-locking |
|
| 2014-01-20 15:58:07 |
Launchpad Janitor |
branch linked |
|
lp:~louis-bouchard/ubuntu/trusty/duplicity/fix-s3-and-add-locking |
|
| 2014-01-20 15:58:43 |
Launchpad Janitor |
branch linked |
|
lp:~louis-bouchard/ubuntu/saucy/duplicity/fix-s3-and-add-locking |
|
| 2014-01-20 15:59:17 |
Launchpad Janitor |
branch linked |
|
lp:~louis-bouchard/ubuntu/raring/duplicity/fix-s3-and-add-locking |
|
| 2014-01-20 16:16:05 |
Louis Bouchard |
description |
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. |
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. |
|
| 2014-01-20 16:16:16 |
Louis Bouchard |
duplicity (Ubuntu Quantal): status |
Triaged |
In Progress |
|
| 2014-01-20 16:16:19 |
Louis Bouchard |
duplicity (Ubuntu Raring): status |
Triaged |
In Progress |
|
| 2014-01-20 16:16:22 |
Louis Bouchard |
duplicity (Ubuntu Saucy): status |
Triaged |
In Progress |
|
| 2014-01-20 16:18:25 |
Louis Bouchard |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2014-01-20 16:18:34 |
Louis Bouchard |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2014-01-21 13:52:10 |
Louis Bouchard |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2014-01-21 13:52:13 |
Louis Bouchard |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2014-01-21 14:18:59 |
Louis Bouchard |
duplicity: status |
Fix Committed |
In Progress |
|
| 2014-01-21 14:49:25 |
Louis Bouchard |
description |
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. |
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
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 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. |
|
| 2014-01-21 15:10:03 |
Louis Bouchard |
description |
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
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 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. |
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
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.lock
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 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. |
|
| 2014-01-22 11:34:47 |
Launchpad Janitor |
branch linked |
|
lp:~louis-bouchard/ubuntu/precise/duplicity/fix-s3-and-add-locking |
|
| 2014-01-22 11:35:10 |
Launchpad Janitor |
branch linked |
|
lp:~louis-bouchard/ubuntu/raring/duplicity/fix-s3-and-add-locking |
|
| 2014-01-22 11:35:23 |
Launchpad Janitor |
branch linked |
|
lp:~louis-bouchard/ubuntu/saucy/duplicity/fix-s3-and-add-locking |
|
| 2014-01-22 11:36:21 |
Launchpad Janitor |
branch linked |
|
lp:~louis-bouchard/ubuntu/trusty/duplicity/fix-s3-and-add-locking |
|
| 2014-01-22 13:01:51 |
Louis Bouchard |
duplicity: status |
In Progress |
Fix Committed |
|
| 2014-01-24 13:13:39 |
Kenneth Loafman |
duplicity: status |
Fix Committed |
Fix Released |
|
| 2014-01-24 13:41:41 |
Louis Bouchard |
attachment added |
|
lp1266763_s3_locking_gpg_precise.debdiff https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3955921/+files/lp1266763_s3_locking_gpg_precise.debdiff |
|
| 2014-01-24 13:42:09 |
Louis Bouchard |
attachment added |
|
lp1266763_s3_locking_raring.debdiff https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3955922/+files/lp1266763_s3_locking_raring.debdiff |
|
| 2014-01-24 13:42:32 |
Louis Bouchard |
attachment added |
|
lp1266763_s3_locking_saucy.debdiff https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3955923/+files/lp1266763_s3_locking_saucy.debdiff |
|
| 2014-01-24 13:42:51 |
Louis Bouchard |
attachment added |
|
lp1266763_s3_locking_trusty.debdiff https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3955924/+files/lp1266763_s3_locking_trusty.debdiff |
|
| 2014-01-24 13:43:37 |
Louis Bouchard |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2014-01-24 13:43:50 |
Louis Bouchard |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2014-02-19 09:17:23 |
Louis Bouchard |
attachment removed |
lp1266763_s3_locking_trusty.debdiff https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3955924/+files/lp1266763_s3_locking_trusty.debdiff |
|
|
| 2014-02-19 09:17:35 |
Louis Bouchard |
attachment removed |
lp1266763_s3_locking_saucy.debdiff https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3955923/+files/lp1266763_s3_locking_saucy.debdiff |
|
|
| 2014-02-19 09:17:47 |
Louis Bouchard |
attachment removed |
lp1266763_s3_locking_raring.debdiff https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3955922/+files/lp1266763_s3_locking_raring.debdiff |
|
|
| 2014-02-19 09:18:00 |
Louis Bouchard |
attachment removed |
lp1266763_s3_locking_gpg_precise.debdiff https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3955921/+files/lp1266763_s3_locking_gpg_precise.debdiff |
|
|
| 2014-02-19 13:50:22 |
Louis Bouchard |
attachment added |
|
lp1266763_s3_locking_trusty_with_breaks.debdiff https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3986714/+files/lp1266763_s3_locking_trusty_with_breaks.debdiff |
|
| 2014-02-19 17:28:02 |
Michael Terry |
duplicity (Ubuntu Trusty): status |
In Progress |
Fix Released |
|
| 2014-02-19 17:28:02 |
Michael Terry |
duplicity (Ubuntu Trusty): assignee |
Louis Bouchard (louis-bouchard) |
|
|
| 2014-02-20 10:32:11 |
Louis Bouchard |
duplicity (Ubuntu Quantal): status |
In Progress |
Won't Fix |
|
| 2014-02-20 10:32:15 |
Louis Bouchard |
duplicity (Ubuntu Raring): status |
In Progress |
Won't Fix |
|
| 2014-02-20 10:32:22 |
Louis Bouchard |
duplicity (Ubuntu Quantal): assignee |
Louis Bouchard (louis-bouchard) |
|
|
| 2014-02-20 10:32:25 |
Louis Bouchard |
duplicity (Ubuntu Raring): assignee |
Louis Bouchard (louis-bouchard) |
|
|
| 2014-02-20 10:36:13 |
Louis Bouchard |
attachment added |
|
lp1266763_s3_locking_saucy_with_breaks.debdiff https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3988011/+files/lp1266763_s3_locking_saucy_with_breaks.debdiff |
|
| 2014-02-20 10:36:38 |
Louis Bouchard |
attachment added |
|
lp1266763_s3_locking_gpg_precise_with_breaks.debdiff https://bugs.launchpad.net/duplicity/+bug/1266763/+attachment/3988012/+files/lp1266763_s3_locking_gpg_precise_with_breaks.debdiff |
|
| 2014-03-05 11:44:53 |
Sebastien Bacher |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2014-03-12 08:10:21 |
Chris Halse Rogers |
duplicity (Ubuntu Saucy): status |
In Progress |
Fix Committed |
|
| 2014-03-12 08:10:30 |
Chris Halse Rogers |
bug |
|
|
added subscriber SRU Verification |
| 2014-03-12 08:10:33 |
Chris Halse Rogers |
tags |
patch |
patch verification-needed |
|
| 2014-03-12 08:18:29 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/saucy-proposed/duplicity |
|
| 2014-03-19 11:29:08 |
Louis Bouchard |
tags |
patch verification-needed |
patch verification-done |
|
| 2014-03-27 20:33:29 |
Brian Murray |
tags |
patch verification-done |
patch verification-done-saucy |
|
| 2014-03-27 20:39:59 |
Brian Murray |
description |
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
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.lock
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 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. |
N.B. This should not be released until after deja-dup bug 1281066.
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
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.lock
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 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. |
|
| 2014-03-27 21:04:38 |
Brian Murray |
duplicity (Ubuntu Precise): status |
In Progress |
Fix Committed |
|
| 2014-03-27 21:04:46 |
Brian Murray |
tags |
patch verification-done-saucy |
patch verification-done-saucy verification-needed |
|
| 2014-03-27 21:28:08 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/precise-proposed/duplicity |
|
| 2014-03-31 08:49:34 |
Louis Bouchard |
tags |
patch verification-done-saucy verification-needed |
patch verification-done verification-done-saucy |
|
| 2014-04-10 23:29:12 |
Launchpad Janitor |
duplicity (Ubuntu Precise): status |
Fix Committed |
Fix Released |
|
| 2014-04-10 23:29:29 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2014-04-10 23:30:01 |
Launchpad Janitor |
duplicity (Ubuntu Saucy): status |
Fix Committed |
Fix Released |
|
| 2014-04-10 23:49:11 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/precise-updates/duplicity |
|
| 2014-04-11 07:17:39 |
Louis Bouchard |
duplicity (Ubuntu Precise): assignee |
Louis Bouchard (louis-bouchard) |
|
|
| 2014-04-11 07:17:42 |
Louis Bouchard |
duplicity (Ubuntu Saucy): assignee |
Louis Bouchard (louis-bouchard) |
|
|
| 2014-12-30 10:49:50 |
Laurent Bigonville |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774183 |
|
| 2014-12-30 10:49:50 |
Laurent Bigonville |
bug task added |
|
duplicity (Debian) |
|
| 2014-12-30 11:47:28 |
Bug Watch Updater |
duplicity (Debian): status |
Unknown |
New |
|
| 2014-12-31 12:21:51 |
Bug Watch Updater |
duplicity (Debian): status |
New |
Fix Released |
|
