Bitcoin 0.14.1
Windows 10 Home v. 1703
Bitcoin Core keeps coming up with the error: «error reading from database, shutting down». I’ve tried deleting the one and only file in the database folder under J:Users custom madeJamesAppDataRoamingBitcoin latestdatabase and restarting the computer, but the same error occurred after the app loaded and was showing the sync progress bar for a minute or so, as previously when the issue occurred today. I am having a similar issue with the Ethereum Mist program, where it crashes after running for a short time. The error on that app also mentioned the filepath to the chaindata. Similarly, I deleted all the chaindata, restarted and the program now has been syncing for many minutes, however it seems like it has started syncing from scratch rather than from where it was up to previously (close to 100%, with only a few thousand blocks left). The debugger for the error in Bitcoin qt in Visual Studio Community says nothing:
asked Jul 9, 2017 at 12:40
1
To fix this problem you will need to reindex. You have already begun that process by delete the chainstate folder. Bitcoin Core will appear as if it is syncing from scratch, but it is not. It is simply reading through all of the block files already on disk and building its databases. If the reindex does not fix your problems, then you may need to actually resync the blockchain, and if that also fails, then you likely have a hardware error.
answered Jul 12, 2017 at 5:59
Andrew Chow♦Andrew Chow
65.1k5 gold badges68 silver badges140 bronze badges
1
Содержание
- bitcoin-qt.exe stops working #6949
- Comments
- Footer
- «error reading from database. shutting down» #22426
- Comments
- Blockchain sync failure #6606
- Comments
- Topic: Error: Error reading from database (Read 261 times)
bitcoin-qt.exe stops working #6949
The application crash error log:
Error reading from database, shutting down
Microsoft Visual C++ Runtime Library
This application has requested the Runtime to terminate in an unusual way.
Problem signature:
Problem Event Name: APPCRASH
Application Name: bitcoin-qt.exe
Application Version: 0.11.1.0
Application Timestamp: 556ba080
Fault Module Name: bitcoin-qt.exe
Fault Module Version: 0.11.1.0
Fault Module Timestamp: 556ba080
Exception Code: 40000015
Exception Offset: 011eefb5
OS Version: 6.0.6002.2.2.0.256.6
Locale ID: 1033
which prevents the block chain from being imported. Similar issues have been reported on the Stack Exchange.
The text was updated successfully, but these errors were encountered:
Can you paste the end of debug.log?
The rest of the error log:
Additional Information 1: 06d4
Additional Information 2: f9337f77c523c7a049cb4c2e00dc872a
Additional Information 3: 131b
Additional Information 4: dfd2c70bac16e3f92e3f905aa6b45cfc
The block chain is on an external USB hard drive since it’s too big for this old Latitude’s primary hard drive. It’s probably something relatively simple but of course unknown to most since the other threads got no response.
Can you post the full debug log or at least the last 50 lines?
I have no clue what the additional information is.
Really need bitcoin core’s debug.log, not OS information
The debug file is attached. Bit Coin Core crashes when started so the programs features are unavailable. The error can be reproduced by reinstallation but that’s not going to resolve anything.
The error message from the debug file:
2015-11-05 14:13:13 LevelDB read failure: Corruption: block checksum mismatch
2015-11-05 14:13:14 Corruption: block checksum mismatch
2015-11-05 14:14:18 Error reading from database: Database corrupted
So your database is clearly corrupt and you suspect there’s something wrong with the program. Why is that?
The latest of over a dozen application crash debug logs:
2015-11-08 14:10:38 Corruption: block checksum mismatch
2015-11-08 14:10:38 *** System error while flushing: Database corrupted
2015-11-08 14:10:45 ERROR: ProcessNewBlock: ActivateBestChain failed
2015-11-08 14:10:46 ERROR: ConnectBlock(): inputs missing/spent
2015-11-08 14:10:46 Misbehaving: 168.158.129.29:8333 (0 -> 100) BAN THRESHOLD EXCEEDED
2015-11-08 14:10:46 InvalidChainFound: invalid block=00000000000005042206cba30b5a8a726ff87478297af2e160e3410b9aa7020c height=192994 log2_work=68.509605 date=2012-08-09 04:39:31
2015-11-08 14:10:46 InvalidChainFound: current best=000000000000003c0df9b9c5e29e00d7fd9da1ddde8bbaca294f5ac06e847dc2 height=192993 log2_work=68.509575 date=2012-08-09 04:28:52
2015-11-08 14:10:46 ERROR: ConnectTip(): ConnectBlock 00000000000005042206cba30b5a8a726ff87478297af2e160e3410b9aa7020c failed
2015-11-08 14:10:46 InvalidChainFound: invalid block=00000000000005042206cba30b5a8a726ff87478297af2e160e3410b9aa7020c height=192994 log2_work=68.509605 date=2012-08-09 04:39:31
2015-11-08 14:10:46 InvalidChainFound: current best=000000000000003c0df9b9c5e29e00d7fd9da1ddde8bbaca294f5ac06e847dc2 height=192993 log2_work=68.509575 date=2012-08-09 04:28:52
2015-11-08 14:10:46 socket send error An operation was attempted on something that is not a socket. (10038)
2015-11-08 14:10:47 ERROR: AcceptToMemoryPool: non-final
2015-11-08 14:10:47 ERROR: AcceptToMemoryPool: non-final
2015-11-08 14:10:47 ERROR: AcceptToMemoryPool: non-final
2015-11-08 14:10:47 ERROR: AcceptToMemoryPool: non-final
2015-11-08 14:10:47 ERROR: AcceptToMemoryPool: non-final
2015-11-08 14:10:47 ERROR: AcceptToMemoryPool: non-final
2015-11-08 14:10:47 net thread interrupt
2015-11-08 14:10:47 msghand thread interrupt
2015-11-08 14:10:47 addcon thread interrupt
2015-11-08 14:10:47 scheduler thread interrupt
2015-11-08 14:10:51 opencon thread interrupt
2015-11-08 14:10:51 Shutdown: In progress.
2015-11-08 14:10:52 StopNode()
2015-11-08 14:10:52 Corruption: block checksum mismatch
2015-11-08 14:10:52 *** System error while flushing: Database corrupted
The block chain is being corrupted during the operation of the program. File corruption has been a continuing problem since the beginning of information technology. The more data that has to be handled the more likely these issues will happen.
You started off with a «bitcoin-qt.exe can’t start», now you’re admitting the blockchain was corrupted before that. Plus there’s already this issue for that: #6528
Ok, your chainstate database is corrupted. You can regenerate it by passing -reindex as a command line argument.
© 2023 GitHub, Inc.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Источник
«error reading from database. shutting down» #22426
This is the first time i was using BitCoin Core and syncing.
Describe the issue: the software fails to sync 100%. It fails around 2020 with the error message «error reading from database. shutting down». Tried restarting a couple times, it makes some more progress then stops somewhere else.
What behavior did you expect? As a first time user I was expecting this to go smooth and sync to be successful.
How reliably can you reproduce the issue, what are the steps to do so? Yes every time I restart it will hit an issue when syncing 2020 and stop.
What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)? I am using the portable version in a zip file, for windows, version 0.21.1
I also checked that the download I used was the right checksum and signed with the right key.
What type of machine are you observing the error on (OS/CPU and disk type)? This is a windows 10 computer with Intel i7-6700HQ
Here are the logs for the latest occurrence:
2021-07-11T02:00:10Z LevelDB read failure: Corruption: block checksum mismatch: D:BitcoinLedgerchainstate/209877.ldb
2021-07-11T02:00:10Z Fatal LevelDB error: Corruption: block checksum mismatch: D:BitcoinLedgerchainstate/209877.ldb
2021-07-11T02:00:10Z You can use -debug=leveldb to get more complete diagnostic messages
2021-07-11T02:00:10Z Error: Error reading from database, shutting down.
2021-07-11T02:00:15Z Error reading from database: Fatal LevelDB error: Corruption: block checksum mismatch: D:BitcoinLedgerchainstate/209877.ldb
I checked my computer for hard drive corruption issues. Copied 50Gbs back and forth with checksum no errors. Memory also checks ok.
When I search the whole logs, the corruption message is always about 209877. Is there a way I can force a re-download or something?
The text was updated successfully, but these errors were encountered:
Источник
Blockchain sync failure #6606
I’m on Bitcoin core v0.11.0 windows x64.
OS is Windows Server 2012 R2.
I’ve been using bitcoin core for years without significant problems, but last month something happened. Database got corrupted. I tried to delete all but wallet.dat, resync database. Tried
5 times, put datadir to different hard drives. At random position sync stops with error. After process relaunch same error is displayed and program crashes with assertion.
The text was updated successfully, but these errors were encountered:
Same thing happens to bitcoind.
C:Program FilesBitcoindaemon>bitcoind.exe -datadir=H:bitcoin
Error: Error reading from database, shutting down.
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application’s support team for more information.
2015-08-31 12:39:34 LevelDB read failure: Corruption: block checksum mismatch
2015-08-31 12:39:34 Corruption: block checksum mismatch
2015-08-31 12:39:34 Error: Error reading from database, shutting down.
2015-08-31 12:39:34 Error reading from database: Database corrupted
«Error reading from database: Database corrupted» levelDB corruption is usually caused by disk or memory corruption (while writing to disk).
You could try using -par=1 to restrict syncing to one thread and then -reindex . Sometimes this helps when, for example, the CPU is overheating.
Unlikely this is RAM or DISK problem. OS runs stable for weeks, memtest report nothing.
No bad block events in the event log. One of the disks I tried to put db on is several days old.
Ram problems are mostly random. Here I have 100% failure result each time.
Any ways to further diagnose the source of the problem ?
I reproduced exact same behavior in VM with Windows Server 2003 X64.
Pls someone try to resync the whole db ! Am I alone with this ?
I’d be interested to know if the same happens in that VM with Bitcoin 10.2.
You are able to reproduce the failure on other hardware?
What about bitcoind or bitcoin-qt for Linux in a VM?
Both 0.10.2 and 0.11.0 cannot start db sync when empty datadir is on «vmware-hostshared folders» and successfully do when datadir is on windows network drive.
2015-09-01 09:51:55 init message: Loading block index.
2015-09-01 09:51:55 Opening LevelDB in Z:home-hBit2testblocksindex
2015-09-01 09:51:55 Corruption: no meta-nextfile entry in descriptor
2015-09-01 09:52:23 init message: Loading block index.
2015-09-01 09:52:23 Wiping LevelDB in Z:home-hBit2testblocksindex
2015-09-01 09:52:23 Opening LevelDB in Z:home-hBit2testblocksindex
2015-09-01 09:52:23 Corruption: no meta-nextfile entry in descriptor
2015-09-01 09:52:25 Shutdown: In progress.
2015-09-01 09:52:25 StopNode()
2015-09-01 09:52:25 Shutdown: done
I have one guess. Trouble can be in memory mapped files. I know bitcoin core uses them, it can be seen in RamMap utility.
I also run BURST coin pocminer. It extensively uses mapped files. Because of that kernel paged pool grows very large — up to more than half of the physical memory (its gigabytes). Huge pooltag is «MmSt», it contain PTEs. Detailed subject description is here : http://blogs.technet.com/b/askperf/archive/2011/09/23/getting-to-know-the-mmst-pool-tag.aspx
I’m on 24 GB system and set the PoolUsageMaximum to 10 (its 10 percent of RAM, 2.4G in my case). This measure effectively limit MmSt growth and it worked great until. what changed in last weeks ?
I replaced failing hard drive which contain 3 TB of BURST miner plots. This time I formatted NTFS volume with 64K cluster size (was 4K).
And probably from that point bitcoin db corruptions started.
Now i killed pocminer and trying to sync bitcoin both on the host and in VM.
Without pocminer bitcoin could start sync on vmware-host shared folder.
Will report after my guess is confirmed or no.
PS. Bitcoin 0.11.0 linux x86, runs on different hardware node without VM. Already synced till 1 year old, still no problem.
Yes, trouble was triggered by BURST miner. Without it sync was successful.
Running with almost exhausted paged pool cause errors not only in bitcoin core but also have other negative effects and having large cluster volume seem to harden them.
Thanks for looking into this so deeply. This issue could be useful for other people that experience issues on windows.
I still wonder how the combination of hw and sw caused corruption, but it’s likely the problem lies outside bitcoin core if it affects other software negatively as well.
One of the negative effects was the following.
Attempts to start db sync from bitcoin core running in vmware guest to vmware host drive were failing just at the start. Then I tried to mount network drive from vm guest to vm host using virtual network (regular ‘net use 192.168.1.5’) and sync db to that drive.
Start was successful but after some time I saw messages in the tray stating that windows could not flush data to network drive and data could be lost. Obviously, bitcoin core cannot display such messages, explorer.exe displays them. Event source is guest os kernel not being able to get read/write success confirmation from the server side. Thus the lanmanserver (The ‘Server’ service) component on the host was experiencing problems in exhausting paged pool condition probably IO-related.
Its all very strange because in the task manager on the host I see that pool is being trimmed from 2.8G to 800M after its exhaustion and then again grows to 2.8G.
I can suppose some paged pool allocations or some map-view-of-file operations fail before MmSt trim actually happens. Kernel components are written well-checked to not crush in any possible condition, but still denial-of-service exists.
Windows architecture problem ? I know burst miner is badly designed. It should not map terabytes of data files to memory. But also OS should not behave bad in this condition. If MmSt pool is like cache it must be trimmed transparently without alloc fails.
From bitcoin core perspective may be some checks are missing or db engine lack enough atomicity to rollback failing changes ? At the moment I can state : BURST miner can kill bitcoin db in some conditions, possibly when burst plots are on a large cluster volume.
This is not HW related at all. Its mainly the OS problem not being too resistant to some conditions.
Источник
Topic: Error: Error reading from database (Read 261 times)
You’ll have to do as nc50lc suggests.
If that doesn’t work and there’s another file corruption, you’ll be better off reindexing to a new folder if you have enough space an dpotentiallu move your current data dir off the drive (you can keep the main parent and just move the blocks and chainstate if you do that).
Now a different file in the chainstate folder is corrupted.
You can delete that particular file and restart but.
Check your HDD for hardware issues like bad sectors first so you wont lose more time on deleting corrupted files and trying over and over.
You can use HDDScan, Hard Disk Sentinel or other disk check-up tool online (most of them work with SSD too).
Hard Disk Sentinel’s output:
The status of the solid state disk is PERFECT. Problematic or weak sectors were not found.
The TRIM feature of the SSD is supported and enabled for optimal performance.
The health is determined by SSD specific S.M.A.R.T. attribute(s): #202 Percentage Of The Rated Lifetime Used
No actions needed.
Most common reason are faulty RAM, failing HDD/SDD or broken SATA cable.
Download crystaldiskinfo and see if there are any warning/caution for your HDD/SSD. If there are any warning/caution, it might be the reason.
Crystaldiskinfo says: 96% Good
— S.M.A.R.T. —————————————————————
ID Cur Wor Thr RawValues(6) Attribute Name
01 100 100 __0 000000000000 Raw Read Error Rate
05 100 100 _10 000000000000 Reallocated NAND Blocks
09 100 100 __0 0000000002C6 Power On Hours
0C 100 100 __0 0000000005E9 Power Cycle Count
AB 100 100 __0 000000000000 Program Fail Count
AC 100 100 __0 000000000000 Erase Fail Count
AD _96 _96 __0 000000000048 Average Block-Erase Count
AE 100 100 __0 00000000001A Unexpected Power Loss Count
B4 __0 __0 __0 000000000025 Unused Reserve NAND Blocks
B7 100 100 __0 000000000000 SATA Interface Downshift
B8 100 100 __0 000000000000 Error Correction Count
BB 100 100 __0 000000000000 Reported Uncorrectable Errors
C2 _51 _32 __0 004400000031 Temperature
C4 100 100 __0 000000000000 Reallocation Event Count
C5 100 100 __0 000000000000 Current Pending Sector Count
C6 100 100 __0 000000000000 Smart Off-line Scan Uncorrectable Error Count
C7 100 100 __0 000000000000 Ultra DMA CRC Error Rate
CA _96 _96 __1 000000000004 Percent Lifetime Used
CE 100 100 __0 000000000000 Write Error Rate
D2 100 100 __0 000000000000 Successful RAIN Recovery Count
F6 100 100 __0 0007AE3B8434 Total Host Sector Writes
F7 100 100 __0 00002038057F Host Program Page Count
F8 100 100 __0 00004F0D845D Background Program Page Count
— IDENTIFY_DEVICE ———————————————————
0 1 2 3 4 5 6 7 8 9
000: 0040 3FFF C837 0010 0000 0000 003F 0000 0000 0000
010: 3138 3436 4531 4436 4136 3233 2020 2020 2020 2020
020: 0000 0000 0000 4D33 4352 3032 3320 4354 3130 3030
030: 4D58 3530 3053 5344 3120 2020 2020 2020 2020 2020
040: 2020 2020 2020 2020 2020 2020 2020 8001 4001 2F00
050: 4001 0000 0000 0006 3FFF 0010 003F FC10 00FB BD01
060: FFFF 0FFF 0000 0007 0003 0078 0078 0078 0078 0D98
070: 0000 0000 0000 0000 0000 001F 850E 0086 014C 0000
080: 07F0 006D 706B 7409 4163 7069 B409 4163 207F 0001
090: 0001 00FE FFFE 0000 0000 0000 0000 0000 0000 0000
100: 6DB0 7470 0000 0000 0000 0008 6003 0000 500A 0751
110: E1D6 A623 0000 0000 0000 0000 0000 0000 0000 411C
120: 401C 0000 0000 0000 0000 0000 0000 0000 0029 4372
130: 7563 6961 6C00 0000 0000 0000 0000 0000 0000 0000
140: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
150: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
160: 0000 0000 0000 0000 0000 0000 0000 0000 0003 0001
170: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
180: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
190: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
200: 0000 0000 0000 0000 0000 0000 0031 0000 0000 4000
210: 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000
220: 0000 0000 11FF 0000 0000 0000 0000 0000 0000 0000
230: 6DB0 7470 0000 0000 0001 0200 0000 0000 0000 0000
240: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
250: 0000 0000 0000 0000 0000 ACA5
— SMART_READ_DATA ———————————————————
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
000: 10 00 01 2F 00 64 64 00 00 00 00 00 00 00 05 32
010: 00 64 64 00 00 00 00 00 00 00 09 32 00 64 64 C6
020: 02 00 00 00 00 00 0C 32 00 64 64 E9 05 00 00 00
030: 00 00 AB 32 00 64 64 00 00 00 00 00 00 00 AC 32
040: 00 64 64 00 00 00 00 00 00 00 AD 32 00 60 60 48
050: 00 00 00 00 00 00 AE 32 00 64 64 1A 00 00 00 00
060: 00 00 B4 33 00 00 00 25 00 00 00 00 00 00 B7 32
070: 00 64 64 00 00 00 00 00 00 00 B8 32 00 64 64 00
080: 00 00 00 00 00 00 BB 32 00 64 64 00 00 00 00 00
090: 00 00 C2 22 00 33 20 31 00 00 00 44 00 00 C4 32
0A0: 00 64 64 00 00 00 00 00 00 00 C5 32 00 64 64 00
0B0: 00 00 00 00 00 00 C6 30 00 64 64 00 00 00 00 00
0C0: 00 00 C7 32 00 64 64 00 00 00 00 00 00 00 CA 30
0D0: 00 60 60 04 00 00 00 00 00 00 CE 0E 00 64 64 00
0E0: 00 00 00 00 00 00 D2 32 00 64 64 00 00 00 00 00
0F0: 00 00 F6 32 00 64 64 34 84 3B AE 07 00 00 F7 32
100: 00 64 64 7F 05 38 20 00 00 00 F8 32 00 64 64 5D
110: 84 0D 4F 00 00 00 00 00 00 00 00 00 00 00 00 00
120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
160: 00 00 00 00 00 00 00 00 00 00 80 00 00 00 00 7B
170: 03 00 01 00 02 1E 02 00 00 00 00 00 00 00 00 00
180: 00 00 4D 33 43 52 30 32 33 20 00 00 00 00 00 00
190: 53 4D 32 32 35 38 42 31 36 41 52 00 00 00 00 00
1A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20
— SMART_READ_THRESHOLD —————————————————-
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
000: 01 00 01 00 00 00 00 00 00 00 00 00 00 00 05 0A
010: 00 00 00 00 00 00 00 00 00 00 09 00 00 00 00 00
020: 00 00 00 00 00 00 0C 00 00 00 00 00 00 00 00 00
030: 00 00 AB 00 00 00 00 00 00 00 00 00 00 00 AC 00
040: 00 00 00 00 00 00 00 00 00 00 AD 00 00 00 00 00
050: 00 00 00 00 00 00 AE 00 00 00 00 00 00 00 00 00
060: 00 00 B4 00 00 00 00 00 00 00 00 00 00 00 B7 00
070: 00 00 00 00 00 00 00 00 00 00 B8 00 00 00 00 00
080: 00 00 00 00 00 00 BB 00 00 00 00 00 00 00 00 00
090: 00 00 C2 00 00 00 00 00 00 00 00 00 00 00 C4 00
0A0: 00 00 00 00 00 00 00 00 00 00 C5 00 00 00 00 00
0B0: 00 00 00 00 00 00 C6 00 00 00 00 00 00 00 00 00
0C0: 00 00 C7 00 00 00 00 00 00 00 00 00 00 00 CA 01
0D0: 00 00 00 00 00 00 00 00 00 00 CE 00 00 00 00 00
0E0: 00 00 00 00 00 00 D2 00 00 00 00 00 00 00 00 00
0F0: 00 00 F6 00 00 00 00 00 00 00 00 00 00 00 F7 00
100: 00 00 00 00 00 00 00 00 00 00 F8 00 00 00 00 00
110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 22
Источник
full member
Activity: 224
Merit: 100
Yes, I do. 
Permissions on the folder has a special group, since some of these folders are shared through SMB, of group smbusers and user smbguest (smbguest is the owner). My account is a member of smbusers. The permissions are rwxrwxrwx for all files in the folder, and the sticky bit is set for the group so it inherits automatically for any file or folder made inside it.
Like I said earlier, what doesn’t make sense is I can click that error message from bitcoin-qt, which then closes the window, then immediately double-click the desktop icon to start it back up and it works fine again, for at least 8-12 hours.
It’s done the same thing every day since I set up the 64-bit version.
I can’t get the 32-bit one to even start up (doesn’t even get to start checking the Blockchain), since there are some 32-bit libraries missing from the Centos install (I set it up as pure 64-bit to start with). When I tried running it the first complaint was it couldn’t find libfontconfig.so (might have been .so.0 on the end, not sure now). So I installed the 32-bit package for that, which cleared that error. But then it says it cannot find a file, but doesn’t say what file, so I can’t go any farther with it. That’s why I went with the 64-bit version when I set it up under Centos this time. I would give the 32-bit one a try to see if it is stable like it’s been everywhere else, but there is nothing in the docs that says what the software dependencies are.
full member
Activity: 224
Merit: 100
When I had it running on my Windows 7 computer, I had the 64-bit installed first (since it was 64-bit Windows). Since it was REALLY unstable (wouldn’t go more than 12 hours without crashing, sometimes corrupting the database and redownloading the blockchain) I then loaded the 32-bit and made sure it loaded the old data files (which were working in the 64-bit version when I shut it down). That worked solid, no problems for at least a month.
I kinda doubt there might be an issue with the files between 32 and 64 bit, at least for Windows anyway. Maybe for Linux though.
When I set up the Fedora VM, I made it 32-bit from the start since I didn’t want to mess with the stability issues like I saw with the Windows 64-bit version. That install had been there for months, starting with the data files that the Windows box had (copied them over and replaced the contents of the Data folder in the linux install).
Hmm, this is odd. Here’s the three lines in debug.log from around when it happened:
2015-12-21 06:00:05 LevelDB read failure: IO error: /storage/Backups/bitcoin/data/chainstate/3047481.ldb: Permission denied
2015-12-21 06:00:05 IO error: /storage/Backups/bitcoin/data/chainstate/3047481.ldb: Permission denied
2015-12-21 14:06:29 Error reading from database: Database I/O error
Interesting that it doesn’t record the error that is prompted until I clicked it this morning (just after 8am CST US time, which matches up to the last time stamp since that is UTC shown).
The line just before the LevelDB entry is from normal operation (lots of entries about the rate limiter kicking in on a free transaction). Not sure why it thinks there is a permission denied issue, since immediately restarting the client works fine.
For reference, the /storage folder is a mount point for a software RAID5 array of four 2 TB drives, formatted EXT4. I’ve got others things (like a Windows VM running in Virtualbox) that have data files stored on that same volume, which were all working fine at the same time this happened.
I checked the kernel’s messages log at midnight, matching up to that time stamp, and there’s nothing odd listed.
full member
Activity: 224
Merit: 100
Lately I changed where my Bitcoin Core install was located, moving the data out from a Fedora VM to the host system and setting up Bitcoin Core 0.11.2 64-bit. The host system is running 64-bit Centos 6 (whatever latest is, kept up to date against repos) on a Core2Quad 2.4 GHz CPU with 8GB RAM in an old Optiplex 755 (server is stable, up 24/7 and rarely gets rebooted). In the 32-bit Fedora VM on the same computer I ran the 32-bit version, and it ran for months without issues. Since moving the data out to the host and loading the client, I can’t get it to stay up for more than 24 hours.
I’ve got the node linked to Bitnodes so I know when it goes up or down, and it’s been very consistent. Data shows steady response times for anywhere from 12-16 hours, then it will either say it stalled or is down. When I check the client, it shows the error «Error reading from database, shutting down». When I ok that, it closes the client immediately.
Odd bit is I can immediately reopen the client and it loads and works (after syncing that is). Granted, I never seem to catch it when it happens, so can’t say if there is anything else that happens just before the error. This Centos box is my home network server, so it’s not monitored unless something isn’t working.
Is there a problem in the 64-bit version? Since I had a similar issue on Windows when trying this (64-bit was seriously not stable with the same error and worked fine after restarting it, 32-bit worked fine for weeks) I tried running the 32-bit version, but can’t figure out what 32-bit packages I need to install to get it working. The Bitcoin Core documentation is seriously lacking in what software requirements there are for Linux machines and the messages I get do not point to specific modules or libs.
So, any ideas on how to fix this?
-
#1
Здравствуйте, решил поставить Bitcoin core, но столкнулся вот с таким великолепием:
Почему-то дальше 30,01% загрузка блоков не идёт, урезание включено, без него вообще не работало.
Ставлю на жёсткий диск ST1500DL003-9VT16L 1500, свободного места 569 гб, всего хватает. Через кристалдиск смотрел, с диском всё хорошо.
Подскажите новичку : что делать? С каким бубном плясать?
Логи прилагаю:
2022-05-12T12:06:00Z LevelDB read failure: Corruption: block checksum mismatch: G:Bitcoinchainstate/152235.ldb
2022-05-12T12:06:00Z Fatal LevelDB error: Corruption: block checksum mismatch: G:Bitcoinchainstate/152235.ldb
2022-05-12T12:06:00Z You can use -debug=leveldb to get more complete diagnostic messages
2022-05-12T12:06:00Z Error: Error reading from database, shutting down.
2022-05-12T12:06:34Z No valid UPnP IGDs found
2022-05-12T12:11:36Z No valid UPnP IGDs found
2022-05-12T12:16:38Z No valid UPnP IGDs found
2022-05-12T12:17:49Z Error reading from database: Fatal LevelDB error: Corruption: block checksum mismatch: G:Bitcoinchainstate/152235.ldb
Понимаю, что ошибка в этом файле, но чо мне с ним делать?) Удалить? Переименовать?
Заранее благодарен за советы, спасибо.
-
Screenshot_1.png
46 КБ · Просмотры: 27
-
#2
А можно вопрос? Зачем вам биткоин кор? Если для использования только в качестве кошелька, то он просто не нужен
-
#3
А можно вопрос? Зачем вам биткоин кор? Если для использования только в качестве кошелька, то он просто не нужен
Почему не нужен? Ну вот хочу я хранить крипту у себя на компьютере на своём диске
Не платить комиссий онлайн кошелькам, не светить паспортом при регистрации на бинансе ))
Разве нужны ещё причины?
-
#4
Почему не нужен? Ну вот хочу я хранить крипту у себя на компьютере на своём диске
Не платить комиссий онлайн кошелькам, не светить паспортом при регистрации на бинансе))
Разве нужны ещё причины?
Для этого есть электрум, более того, его можно использовать гораздо безопаснее биткоин кора.
Ну а по теме, снести файл, на который он ругается, и запустить, может прокатит. Либо полная пересинхронизация.
-
#5
Если Семеныч сейчас в хорошем настроении, он тебе лекцию прочитает
-
#6
Для этого есть электрум, более того, его можно использовать гораздо безопаснее биткоин кора.
0_0
Да уж, я совсем несведущ. Мне казалось самое безопасное это биткоин кор.
-
#7
Мне казалось самое безопасное это биткоин кор.
Самое безопасное — это офлайн подпись транзакций на устройстве, которое не знает, что такое интернет. Использовать для этого биткоин кор — нецелесообразно, как минимум потому что нужно обладать определенными знаниями и скиллами. А вот электрум в этом смысле намного проще и понятнее. Если же мы говорим о горячем использовании, а это именно то, что вы сейчас пытаетесь наладить, то никаких преимуществ в использовании биткон кора нет. Нода, она же полный узел, используется совсем для других целей. Например, для майнинг пула, или для сервера того же электрума, чтобы другие могли им пользоваться. Фишка в чём, если использовать лайт клиент, вы подключаетесь к удалённой ноде того же биткоин кора, но ключи находятся на вашей стороне, и смысл разворачивать свой полный клиент в данном случае отсутствует
-
Ответов
3.7т -
Создана
7 Aug 2011, 20:14 -
Последний ответ
28 Jan 2023, 12:06
Топ авторов темы
-
178
-
170
-
148
-
118
Популярные посты
polym0rph
7 Aug 2011, 20:14
Bitcoin Core — это полноценный клиент, составляющий основу сети. Для него характерен высокий уровень безопасности, конфиденциальности и стабильности. Однако, у него меньше опций и он занимает довольно
Lexis77
9 Sep 2015, 21:52
Странные вы люди! Хранить порнухи на 100Гб — нормально, а на кошель 50Гб — жалко… 
man, you made my day!
Исходники не изменятся когда номер блока, с которого произойдет разделение сети, станет известным. Просто пользоваться им ( кошельком) надо уже после того, к
Изображения в теме
Для публикации сообщений создайте учётную запись или авторизуйтесь
Вы должны быть пользователем, чтобы оставить комментарий
Войти
Уже есть аккаунт? Войти в систему.
Войти
-
Home
-
Forums
New posts
All threads
Latest threads
New posts
Trending threads
Trending
Search forums
-
What’s new
New posts
New profile posts
-
New Users
New User Safety Guidelines
Dash for Newbies
Wallets
Glossary
How to Buy Dash
What is Dash?
-
Docs
Getting Started
Features
Wallets
Governance and Budget
Mining
Masternodes
Developer Documentation
-
Members
Registered members
Current visitors
New profile posts
Search profile posts
-
Markets
Charts
Exchanges
CoinMarketCap
Coingecko
-
Merchants
DashDirect
Payment Processors
Techical Guides
Marketing Material
-
Masternodes
Masternode Information
Masternode Statistics
Hosting Services
Masternode Stats TV
Setup Guide
-
Network
Statistics
Masternode Data
Dash Ninja
Insight Explorer
Blockchair Explorer
GitHub
-
Voting
Dash Central
Dash Watch
Proposal Generator
Voting Procedures
-
News
Dash Core Group Blog
Dash Newsroom
DashNewsItalia
Dash News En Español
Dash News Korea
Dash Vietnam
-
Social Media
Twitter
Facebook
Minds
YouTube
Reddit
Steemit
LinkedIn
-
Chat
Dash Discord
Dash Devs Discord
Telegram: English
Telegram: Russian
Telegram: Italian
Telegram: Spanish
Telegram: Brazil/Portuguese
QQ达世币官方群 Chinese
Error reading from database, shutting down
-
Thread starternmarley
-
Start dateMay 20, 2016
-
Home -
Forums
-
Dash Currency
-
Dash Support
-
Daemon and QT Wallet Support
nmarley
Administrator
-
- Jun 28, 2014
-
- 369
-
- 427
-
- 133
May 20, 2016
-
#1
2016-05-20 07:47:17 LevelDB read failure: Corruption: block checksum mismatch
2016-05-20 07:47:17 Corruption: block checksum mismatch
2016-05-20 07:47:17 P2P peers available. Skipped DNS seeding.
2016-05-20 07:47:17 dnsseed thread exit
nmarley
Administrator
-
- Jun 28, 2014
-
- 369
-
- 427
-
- 133
May 20, 2016
-
#2
UdjinM6
Official Dash Dev
-
- May 20, 2014
-
- 3,639
-
- 3,537
-
- 1,183
May 20, 2016
-
#3
You must log in or register to reply here.
Share:
Link
Bottom