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"))
-
Delete all /parity/cache files and it should resume syncing from where it had stopped.– MM_MarioMichelDec 19, 2017 at 17:11
-
@MM_MarioMichel where are those cache files now with Openethereum?– user2284570Feb 16, 2021 at 9:54
Add a comment
|
3 Answers
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.
answered Dec 5, 2016 at 19:35
-
Client service error: Client(Database("IO error: lock /Users/--------/.parity/906a34e69aec8c0d/v5.3-sec-overlayrecent/db/LOCK: Resource temporarily unavailable"))– b glenDec 6, 2016 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 likelsof | grep 906a34e69aec8c0d. When you find which process is holding the lock, kill it withkill <process_id>. Dec 6, 2016 at 14:12 -
yes parity is still running in the background from the macos installer, i've tried– b glenDec 7, 2016 at 13:56
-
tried $ kill parity_906a34e69aec8c0d -bash: kill: parity_906a34e69aec8c0d: arguments must be process or job IDs next?– b glenDec 7, 2016 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? Feb 16, 2021 at 9:57
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.
-
-
Doesn't work for me for some reason: gist.github.com/Pzixel/c2607b035bcb0208a899111b426c23b4 Mar 21, 2018 at 8:33
-
I have manually removed everything from
%LOCALAPPDATA%\Parity\Ethereum\chainsand it helped. Mar 21, 2018 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? Feb 16, 2021 at 9:58
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.
answered Aug 19, 2017 at 16:33
-
What if the issue lies with a block which was corrupted years ago and unoticed? Feb 16, 2021 at 9:59