The same block is always repeated and does not continue downloading

[kekowar]

Hello everyone, i recently installed raspberry with 1 tera hard drive. I have 30Mb with my internet provider.

I did the command install and it is currently downloading.

The problem I have is that bitcoind stops when it reaches 1245mb and the screen indicates killed.
This has happened to me several times already and when I restart bitcoind it continues. The fact is that in block 269, it ends it but when you use the bitcoin command to conitnue download, that block is restarted and the same block is downloaded again without continuing with the one already downloaded.

some help please

https://i.ibb.co/0ZdLPbM/Captura-de-pantalla-de-2021-02-01-09-24-06.png

[NotATether]

If you see see a "Killed" message it means some other process on the OS terminated bitcoin core, almost always a system process.

Processes usually get killed for exhausting all the system resources, such as memory or file handles. How much memory does your raspberry Pi have? I have seen Bitcoin Core take over 2GB at some points in time.

[kekowar]

If you see see a "Killed" message it means some other process on the OS terminated bitcoin core, almost always a system process.

Processes usually get killed for exhausting all the system resources, such as memory or file handles. How much memory does your raspberry Pi have? I have seen Bitcoin Core take over 2GB at some points in time.

Thanks for your response. Exactly, my raspberry has 2Gb RAM. I followe this process to install getting some things from both articles https://howchoo.com/bitcoin/run-bitcoin-full-node-raspberry-pi and https://loveraofficial.medium.com/como-montar-un-nodo-de-bitcoin-en-un-raspberry-pi4b-4gb-parte-1-13c20baabbfb

Then, what would you recomend me?

Thanks in advance.

Here repeting the process in the same block. I'm going to test again downloading to share the result.

Code:

bitcoind
2021-02-02T01:59:14Z Bitcoin Core version v0.21.0 (release build)
2021-02-02T01:59:14Z InitParameterInteraction: parameter interaction: -proxy set -> setting -upnp=0
2021-02-02T01:59:14Z InitParameterInteraction: parameter interaction: -proxy set -> setting -discover=0
2021-02-02T01:59:14Z Assuming ancestors of block 0000000000000000000b9d2ec5a352ecba0592946514a92f14319dc2b367fc72 have valid signatures.
2021-02-02T01:59:14Z Setting nMinimumChainWork=00000000000000000000000000000000000000001533efd8d716a517fe2c5008
2021-02-02T01:59:14Z Using the 'standard' SHA256 implementation
2021-02-02T01:59:15Z Default data directory /home/bitcoin/.bitcoin
2021-02-02T01:59:15Z Using data directory /home/bitcoin/.bitcoin
2021-02-02T01:59:15Z Config file: /home/bitcoin/.bitcoin/bitcoin.conf
2021-02-02T01:59:15Z Config file arg: dbcache="2000"
2021-02-02T01:59:15Z Config file arg: listen="1"
2021-02-02T01:59:15Z Config file arg: listenonion="1"
2021-02-02T01:59:15Z Config file arg: maxconnections="40"
2021-02-02T01:59:15Z Config file arg: maxuploadtarget="5000"
2021-02-02T01:59:15Z Config file arg: proxy="127.0.0.1:9050"
2021-02-02T01:59:15Z Config file arg: rpcpassword=****
2021-02-02T01:59:15Z Config file arg: rpcuser=****
2021-02-02T01:59:15Z Config file arg: server="1"
2021-02-02T01:59:15Z Config file arg: zmqpubrawblock="tcp://127.0.0.1:28332"
2021-02-02T01:59:15Z Config file arg: zmqpubrawtx="tcp://127.0.0.1:28333"
2021-02-02T01:59:15Z Using at most 40 automatic connections (128000 file descriptors available)
2021-02-02T01:59:15Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2021-02-02T01:59:15Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2021-02-02T01:59:15Z Script verification uses 3 additional threads
2021-02-02T01:59:15Z scheduler thread start
2021-02-02T01:59:15Z HTTP: creating work queue of depth 16
2021-02-02T01:59:15Z Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcauth for rpcauth auth generation.
2021-02-02T01:59:15Z HTTP: starting 4 worker threads
2021-02-02T01:59:15Z Using wallet directory /home/bitcoin/.bitcoin
2021-02-02T01:59:15Z init message: Verifying wallet(s)...
2021-02-02T01:59:15Z init message: Loading banlist...
2021-02-02T01:59:15Z SetNetworkActive: true
2021-02-02T01:59:15Z Using /16 prefix for IP bucketing
2021-02-02T01:59:15Z Cache configuration:
2021-02-02T01:59:15Z * Using 2.0 MiB for block index database
2021-02-02T01:59:15Z * Using 8.0 MiB for chain state database
2021-02-02T01:59:15Z * Using 1014.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2021-02-02T01:59:15Z init message: Loading block index...
2021-02-02T01:59:15Z Switching active chainstate to Chainstate [ibd] @ height -1 (null)
2021-02-02T01:59:15Z Opening LevelDB in /home/bitcoin/.bitcoin/blocks/index
2021-02-02T01:59:19Z Opened LevelDB successfully
2021-02-02T01:59:19Z Using obfuscation key for /home/bitcoin/.bitcoin/blocks/index: 0000000000000000
2021-02-02T01:59:35Z LoadBlockIndexDB: last block file = 269
2021-02-02T01:59:35Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=133, size=46578747, heights=356495...356719, time=2015-05-15...2015-05-16)
2021-02-02T01:59:35Z Checking all blk files are present...
2021-02-02T01:59:35Z Opening LevelDB in /home/bitcoin/.bitcoin/chainstate
2021-02-02T01:59:35Z Opened LevelDB successfully
2021-02-02T01:59:35Z Using obfuscation key for /home/bitcoin/.bitcoin/chainstate: 488b9664c97a3456
2021-02-02T01:59:36Z Loaded best chain: hashBestChain=00000000000000000d2b4f43faa197a01b82c4996635c5b67be018ef5d20e92e height=323975 date=2014-10-05T15:07:53Z progress=0.078894
2021-02-02T01:59:36Z init message: Rewinding blocks...
2021-02-02T01:59:40Z FlushStateToDisk: write coins cache to disk (0 coins, 0kB) started
2021-02-02T01:59:40Z FlushStateToDisk: write coins cache to disk (0 coins, 0kB) completed (0.00s)
2021-02-02T01:59:40Z init message: Verifying blocks...
2021-02-02T01:59:40Z Verifying last 6 blocks at level 3
2021-02-02T01:59:40Z [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE].
2021-02-02T02:00:26Z No coin database inconsistencies in last 6 blocks (3434 transactions)
2021-02-02T02:00:26Z  block index           71202ms
2021-02-02T02:00:26Z block tree size = 668370
2021-02-02T02:00:26Z nBestHeight = 323975
2021-02-02T02:00:26Z loadblk thread start
2021-02-02T02:00:26Z Bound to [::]:8333
2021-02-02T02:00:26Z torcontrol thread start
2021-02-02T02:00:26Z Bound to 0.0.0.0:8333
2021-02-02T02:00:26Z Bound to 127.0.0.1:8334
2021-02-02T02:00:26Z init message: Loading P2P addresses...
2021-02-02T02:00:26Z tor: Got service ID aiedcfkq5f6ksexisfkifold5ch2ndhzivdzfccayhqtzz5ltllvflid, advertising service aiedcfkq5f6ksexisfkifold5ch2ndhzivdzfccayhqtzz5ltllvflid.onion:8333
2021-02-02T02:00:26Z AddLocal(aiedcfkq5f6ksexisfkifold5ch2ndhzivdzfccayhqtzz5ltllvflid.onion:8333,4)
2021-02-02T02:00:27Z Loaded 41972 addresses from peers.dat  602ms
2021-02-02T02:00:27Z ERROR: DeserializeFileDB: Failed to open file /home/bitcoin/.bitcoin/anchors.dat
2021-02-02T02:00:27Z 0 block-relay-only anchors will be tried for connections.
2021-02-02T02:00:27Z init message: Starting network threads...
2021-02-02T02:00:27Z net thread start
2021-02-02T02:00:27Z dnsseed thread start
2021-02-02T02:00:27Z Waiting 300 seconds before querying DNS seeds.
2021-02-02T02:00:27Z init message: Done loading
2021-02-02T02:00:27Z msghand thread start
2021-02-02T02:00:27Z addcon thread start
2021-02-02T02:00:27Z opencon thread start
2021-02-02T02:00:30Z UpdateTip: new best=000000000000000015fcad607cfec8bc8a9a8ed14ef3638543c880eeee8c7014 height=323976 version=0x00000002 log2_work=80.969957 tx=48203238 date='2014-10-05T15:11:41Z' progress=0.078895 cache=0.6MiB(5777txo)

[ranochigo]

Lower your dbcache. You've set your dbcache to 2000 which would essentially use your entire ram that your RPi has, and I don't think Bitcoin Core will automatically lowers it. The likely case is that some of the UTXOs gets dumped onto the ram fairly quickly and exhausted it. Delete the dbcache configuration or put a more conservative estimate, say 100MB and observe your processes. You can increase it slightly if it doesn't consume all your ram.

[NotATether]

Lower your dbcache. You've set your dbcache to 2000 which would essentially use your entire ram that your RPi has, and I don't think Bitcoin Core will automatically lowers it. The likely case is that some of the UTXOs gets dumped onto the ram fairly quickly and exhausted it. Delete the dbcache configuration or put a more conservative estimate, say 100MB and observe your processes. You can increase it slightly if it doesn't consume all your ram.

Note that the Linux out-of-memory killer is triggered when the combined RAM plus all the swap space (devices and files) are nearly exhausted so assuming Raspbian allocates 2GB of swap, then that means Core must have been using around 3GB, as the OS itself uses 512MB of memory for itself.

If only the RAM is exhausted then naturally, memory pages of processes will start being moved to swap, and as Linux's swap scheduler isn't as efficient as the one in Windows, it's far more likely that your Linux system will just hang when all the RAM is filled because all the CPU cycles are being spent moving pages between bitcoin core from RAM and swap and back again each time Core uses a memory page located in swap.

A dbcache of 500 should leave enough RAM for other processes to breathe with.

[HCP]

This has happened to me several times already and when I restart bitcoind it continues. The fact is that in block 269, it ends it but when you use the bitcoin command to conitnue download, that block is restarted and the same block is downloaded again without continuing with the one already downloaded.

You seem to be misunderstanding what "block 269" is...

Code:

2021-02-02T01:59:35Z LoadBlockIndexDB: last block file = 269
2021-02-02T01:59:35Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=133, size=46578747, heights=356495...356719, time=2015-05-15...2015-05-16)

It isn't stopping on block# 269... it is stopping on the block file that Bitcoin Core is storing on disk... as you can see, that file actually has 133 blocks stored in it... from Block# 356495 through to Block# 356719



And zooming in on your very small screenshot, it's possible to see that Bitcoin Core is indeed getting a lot of "updateTip", so is in fact syncing "OK" (at least, up until it gets killed! )

As the others have said, the limited RAM on the Pi is likely your issue... especially with the dbcache setting you have used. dbcache should never really be more than half of your total system RAM (as a maximum!)... and you should only really increase it about the default value when you have a fairly substantial amount of system RAM.

Remove the dbcache setting... and you'll find your Pi should happily (but somewhat slowly) sync without being killed

[kekowar]

Note that the Linux out-of-memory killer is triggered when the combined RAM plus all the swap space (devices and files) are nearly exhausted so assuming Raspbian allocates 2GB of swap, then that means Core must have been using around 3GB, as the OS itself uses 512MB of memory for itself.

If only the RAM is exhausted then naturally, memory pages of processes will start being moved to swap, and as Linux's swap scheduler isn't as efficient as the one in Windows, it's far more likely that your Linux system will just hang when all the RAM is filled because all the CPU cycles are being spent moving pages between bitcoin core from RAM and swap and back again each time Core uses a memory page located in swap.

A dbcache of 500 should leave enough RAM for other processes to breathe with.

You seem to be misunderstanding what "block 269" is...

Code:

2021-02-02T01:59:35Z LoadBlockIndexDB: last block file = 269
2021-02-02T01:59:35Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=133, size=46578747, heights=356495...356719, time=2015-05-15...2015-05-16)

It isn't stopping on block# 269... it is stopping on the block file that Bitcoin Core is storing on disk... as you can see, that file actually has 133 blocks stored in it... from Block# 356495 through to Block# 356719

As the others have said, the limited RAM on the Pi is likely your issue... especially with the dbcache setting you have used. dbcache should never really be more than half of your total system RAM (as a maximum!)... and you should only really increase it about the default value when you have a fairly substantial amount of system RAM.

Remove the dbcache setting... and you'll find your Pi should happily (but somewhat slowly) sync without being killed

Thank you very much for the explanation.
I have been testing the network before writing in case there were any problems.

The result is positive and since lowered the RAM to 500. It has been working without interruptions.