Package: obnam
Version: 1.0-1
Severity: normal
I managed to leave a repository locked, and the force-lock command
didn't seem to be able to unlock it. I managed to do this on my initial
backup, when I didn't realise that my secret key was stored with a
passphrase.
Here you can see how to reproduce this (9ea3bc23 is a PGP key with a
passphrase, I'm removing GPG_AGENT_INFO from the environment so that the
backup operation fails):
$ rm -rf /tmp/newrepo
$ GPG_AGENT_INFO= obnam --repository=/tmp/newrepo
--encrypt-with=9ea3bc23 backup Documents
ERROR: gpg: gpg-agent is not available in this session
gpg: can't query passphrase in batch mode
gpg: Invalid passphrase; please try again ...
gpg: can't query passphrase in batch mode
gpg: Invalid passphrase; please try again ...
gpg: can't query passphrase in batch mode
gpg: decryption failed: secret key not available
$ cat /tmp/newrepo/lock
[lockfile]
client=2e8445dc128ddcbbba528fbd5d8b8034
pid=78957
boot_id=f102461d-45fd-43f2-af85-5d982b11f6c0
$ GPG_AGENT_INFO= obnam --repository=/tmp/newrepo
--encrypt-with=9ea3bc23 force-lock
Warning: Client does not exist in repository.
$ echo $?
0
$ cat /tmp/newrepo/lock
[lockfile]
client=2e8445dc128ddcbbba528fbd5d8b8034
pid=78957
boot_id=f102461d-45fd-43f2-af85-5d982b11f6c0
I think this happens because the backup operation doesn't get far enough
to record client information in the repo, but the force-lock operation
seems to depend on the client being recognised:
$ obnam --repository=/tmp/newrepo clients
ERROR: leela is not an existing client
Compare this to what happens if I erase the repo and start again, this
time backing up without the --encrypt-with option. If I send SIGKILL to
the obnam process, lockfiles are left behind, but 'lock-files' manages to
remove them, and 'clients' lists my host.
Now, #675822 and #675965 both mention lockfiles being left behind when
operations fail, so I assume that the lockfile being left behind in this
instance is a generic issue that happens when various operations fail.
And I see #675825 which mentions this issue but doesn't talk about
force-lock failing. So the scope of this bug is simply that the message
output by force-lock is a warning && that force-lock exits with status
0. Instead it should exit with a non-zero status and I suggest also
changing the Warning to an Error, since it seems to be the cause of the
failure. Some supplementary information about how to fix the problem
could also be output (erase the repository if it's a newly created one,
or use --client-name to impersonate a recognised client if trying to
break the lock in a repository that contains data).
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (530, 'testing'), (520, 'unstable'), (510, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages obnam depends on:
ii libc6 2.13-33
ii python 2.7.2-10
ii python-cliapp 0.29-1
ii python-larch 1.20120527-1
ii python-paramiko 1.7.7.1-2
ii python-tracing 0.6-2
ii python-ttystatus 0.18-1
ii python2.6 2.6.7-4
ii python2.7 2.7.3~rc2-2.1
obnam recommends no packages.
obnam suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
