6

Starting Parity/v1.5.0-unstable-0c7b7fc-20161204/x86_64-macos/rustc1.13.0

2016-12-04 18:50:47 State DB configuration: fast

2016-12-04 18:50:47 Operating mode: active

2016-12-04 18:50:47 Configured for Frontier/Homestead using Ethash engine

Client service error: Client(Database("Invalid argument: You have to open all column families. Column families not opened: col5, col4, col3, col2, col1, col0"))

2
  • Delete all /parity/cache files and it should resume syncing from where it had stopped. – MM_MarioMichel Dec 19 '17 at 17:11
  • @MM_MarioMichel where are those cache files now with Openethereum? – user2284570 Feb 16 at 9:54
4

The cause of this is probably a corrupt database, itself caused by Parity having previously been shutdown in an ungraceful manner.

The error you're seeing is covered by issue #2201, but was fixed in #3020. I'm struggling to see which version the fix went into, but presumably not v1.5.0-unstable, which is what you're running.

The recommendation in the notes to #2201 is to delete your blockchain data and re-sync from scratch.

5
  • Client service error: Client(Database("IO error: lock /Users/--------/.parity/906a34e69aec8c0d/v5.3-sec-overlayrecent/db/LOCK: Resource temporarily unavailable")) – b glen Dec 6 '16 at 0:25
  • Is Parity still running in the background? On the terminal, try ps faux | grep parity. Failing that, you could check which process has the lock using something like lsof | grep 906a34e69aec8c0d. When you find which process is holding the lock, kill it with kill <process_id>. – Richard Horrocks Dec 6 '16 at 14:12
  • yes parity is still running in the background from the macos installer, i've tried – b glen Dec 7 '16 at 13:56
  • tried $ kill parity_906a34e69aec8c0d -bash: kill: parity_906a34e69aec8c0d: arguments must be process or job IDs next? – b glen Dec 7 '16 at 14:09
  • @RichardHorrocks since re sync from scratch now takes 2 years in the case of a full archive even when using cutting edge cpu for single thread performance, how to just reset the database to the block before it was broken? – user2284570 Feb 16 at 9:57
3

This is often caused by a corrupted database and can be solved by resetting it completely with:

parity db kill

This wipes the chain and the state and causes a full resync, but enables you to use parity again.

4
  • This worked great. takes a while to resync but it works. – Pitchinnate Aug 29 '17 at 21:03
  • Doesn't work for me for some reason: gist.github.com/Pzixel/c2607b035bcb0208a899111b426c23b4 – Alex Zhukovskiy Mar 21 '18 at 8:33
  • I have manually removed everything from %LOCALAPPDATA%\Parity\Ethereum\chains and it helped. – Alex Zhukovskiy Mar 21 '18 at 8:38
  • @Afr since re sync from scratch now takes 2 years in the case of a full archive even when using cutting edge cpu for single thread performance, how to just reset the database to the block before it was broken? – user2284570 Feb 16 at 9:58
2

I just encountered this error when transferring a Parity node from one server to another.

My issue was that I (foolishly) rsynced the chain data to the new server without having stopped the node. As such the database was corrupted.

Interestingly, if you are transferring a 'live' node, this may be the best way of doing things.

As you may know, by default rsync syncs new or modified files. I synced the files whilst the node was running. This took approximately 40 minutes. After it had completed (and would not load), I stopped the node and rsynced again. This synced only the modified files and took a matter of seconds. My new node was no longer corrupt, and my downtime was a matter of seconds.

1
  • What if the issue lies with a block which was corrupted years ago and unoticed? – user2284570 Feb 16 at 9:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.