Opened at 2014-06-10T22:27:08Z
Last modified at 2014-12-19T02:52:32Z
#2243 assigned defect
TypeError: 'NoneType' object has no attribute '__getitem__' while opening backupdb
Reported by: | daira | Owned by: | daira |
---|---|---|---|
Priority: | normal | Milestone: | undecided |
Component: | code-frontend-cli | Version: | 1.10.0 |
Keywords: | tahoe-backup backupdb error | Cc: | |
Launchpad Bug: |
Description
$ tahoe --version allmydata-tahoe: 1.10.0 foolscap: 0.6.4 pycryptopp: 0.6.0.1206569328141510525648634803928199668821045408958 zfec: 1.4.5 Twisted: 13.2.0 Nevow: 0.10.0 zope.interface: unknown python: 2.7.7 platform: Linux-debian_jessie/sid-i686-32bit_ELF pyOpenSSL: 0.13.1 simplejson: 3.5.2 pycrypto: 2.6.1 pyasn1: 0.1.7 mock: 1.0.1 setuptools: 3.6 $ tahoe backup ~ LAE:backups Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/allmydata/scripts/runner.py", line 156, in run rc = runner(sys.argv[1:], install_node_control=install_node_control) File "/usr/lib/python2.7/dist-packages/allmydata/scripts/runner.py", line 141, in runner rc = cli.dispatch[command](so) File "/usr/lib/python2.7/dist-packages/allmydata/scripts/cli.py", line 574, in backup rc = tahoe_backup.backup(options) File "/usr/lib/python2.7/dist-packages/allmydata/scripts/tahoe_backup.py", line 325, in backup return bu.run() File "/usr/lib/python2.7/dist-packages/allmydata/scripts/tahoe_backup.py", line 90, in run self.backupdb = backupdb.get_backupdb(bdbfile, stderr) File "/usr/lib/python2.7/dist-packages/allmydata/scripts/backupdb.py", line 84, in get_backupdb version = c.fetchone()[0] TypeError: 'NoneType' object has no attribute '__getitem__'
Attachments (1)
Change History (8)
Changed at 2014-06-10T22:35:42Z by zwick
comment:1 follow-up: ↓ 2 Changed at 2014-06-10T22:54:21Z by zooko
Line 84 is merely reading the *version* of the backupdb, so this particular one must have been corrupted. I haven't looked at it yet.
zwick: what happens when you rm it (or mv it aside) and then try again?
comment:2 in reply to: ↑ 1 Changed at 2014-06-11T00:57:27Z by zwick
Replying to zooko:
Line 84 is merely reading the version of the backupdb, so this particular one must have been corrupted. I haven't looked at it yet.
zwick: what happens when you rm it (or mv it aside) and then try again?
mv'ing (moving it aside by renaming it to backupdb.sqlite.BACKUP) and then running the "tahoe backup" command again worked correctly.
comment:3 follow-up: ↓ 5 Changed at 2014-06-11T09:16:04Z by daira
Can you think of anything that might have caused the original file to be corrupted -- was a previous tahoe backup interrupted, for example?
comment:4 Changed at 2014-06-11T09:16:55Z by daira
- Owner set to daira
- Status changed from new to assigned
comment:5 in reply to: ↑ 3 ; follow-up: ↓ 6 Changed at 2014-06-11T16:36:37Z by zwick
Replying to daira:
Can you think of anything that might have caused the original file to be corrupted -- was a previous tahoe backup interrupted, for example?
I cannot recall anything that happened prior to this. I did a clean install of tahoe-lafs and was following the steps at: https://leastauthority.com/howtoconfigure. I am going to do a clean install on a different machine running the same versions of everything (except it will be 64bit instead of 32bit) and see if the same thing happens.
comment:6 in reply to: ↑ 5 Changed at 2014-06-11T17:45:42Z by zwick
Replying to zwick:
Replying to daira:
Can you think of anything that might have caused the original file to be corrupted -- was a previous tahoe backup interrupted, for example?
I cannot recall anything that happened prior to this. I did a clean install of tahoe-lafs and was following the steps at: https://leastauthority.com/howtoconfigure. I am going to do a clean install on a different machine running the same versions of everything (except it will be 64bit instead of 32bit) and see if the same thing happens.
On a different machine, I did a clean install of tahoe-lafs,followed the steps at the URL above, and everything worked correctly. The only difference between these two machines is that the one that had the error uses a 32bit kernel/userspace and the later (that ran without issues) uses a 64bit kernel/userspace.
comment:7 Changed at 2014-12-19T02:52:32Z by zooko
This happened again, with AB:
Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/allmydata/scripts/runner.py", line 156, in run rc = runner(sys.argv[1:], install_node_control=install_node_control) File "/usr/lib64/python2.7/site-packages/allmydata/scripts/runner.py", line 141, in runner rc = cli.dispatch[command](so) File "/usr/lib64/python2.7/site-packages/allmydata/scripts/cli.py", line 574, in backup rc = tahoe_backup.backup(options) File "/usr/lib64/python2.7/site-packages/allmydata/scripts/tahoe_backup.py", line 325, in backup return bu.run() File "/usr/lib64/python2.7/site-packages/allmydata/scripts/tahoe_backup.py", line 90, in run self.backupdb = backupdb.get_backupdb(bdbfile, stderr) File "/usr/lib64/python2.7/site-packages/allmydata/scripts/backupdb.py", line 84, in get_backupdb version = c.fetchone()[0] TypeError: 'NoneType' object has no attribute '__getitem__'
What should we do if the backupdb file is corrupted? Delete it and proceed? Or stop with a useful error message?
The original backupdb.sqlite file that was created