<ol>
<li><p><strong>"Is there a problem with 0.9.3 that causes it to fall behind?</strong> That's a serious problem for the network, but I haven't heard anyone else report it.  If you debug it and discover that it's Bitcoin Core's fault, please <a href="https://github.com/bitcoin/bitcoin/issues/new" rel="nofollow">report it</a>.  However, here are a few common reasons for problems:</p>

<ul>
<li><p><strong>Insufficient resources:</strong> if you're running Bitcoin Core on an underpowered VPS, Raspberry Pi, or other marginal hardware, you'll get all sorts of strange problems.  I recommend a minimum of 1 gigabyte memory for a full node.</p></li>
<li><p><strong>Hardware problems:</strong> bad memory, failing disks, and especially CPU overheating issues can cause your node to stop working or fail validation of a block.</p></li>
<li><p><strong>Suspend/Hibernate issues:</strong> when restoring from suspend/hibernate on Linux, my nodes sometimes take a long time to reestablish connections and start downloading blocks, meaning my node looks like it has fallen behind for awhile.</p></li>
<li><p><strong>Clock issues:</strong> if the clock on a computer falls behind real time by more than about 2 hours, it may not accept the most recent blocks.</p></li>
</ul></li>
<li><p><strong>"Do I need to update to 0.10.0?"</strong> Right now 0.10.0 is in the Release Candidate (RC) phase, which is the last testing phase.  If you'd like to help test, feel free to upgrade.  But if you're relying on Bitcoin Core behaving correctly, staying on most recent released version (0.9.3) is advised.</p></li>
<li><p><strong>"When will 0.10.0 be released?</strong> When the developers think it has been well tested, and not a minute earlier.  I know major software companies often release software on a set schedule, but they do it by holding back (hopefully) release-quality software.  Open source doesn't work that way---everyone can see the source code, so you either release when it's ready or someone else releases it for you. :-)</p></li>
</ol>

<hr>

<h2>Debugging Tips</h2>

<p>I highly recommend that you try to find out what causes your nodes to behave incorrectly or you're likely to have the same problem on 0.10.0 that you have on 0.9.3.  Here are some quick tips:</p>

<ul>
<li><p>Check <code>$HOME/.bitcoin/debug.log</code> for any warnings or errors.  If you can't figure out any messages using a web search, feel free to ask here.</p></li>
<li><p>Start bitcoind with <code>-debug</code> to log additional information.  Note, this will make your log file grow in size faster than normal, and it will inhibit shrinking the logfile on startup for as long as you use it.</p></li>
<li><p>If you only rarely check your nodes, scanning the whole log might be hard.  I suggest starting at the time indicated in the header of the old block you're stuck on.  For example, if you're stuck on block 330,000, </p>

<ul>
<li><p>run <code>bitcoin-cli getblockhash 3330000</code> to get the block's header hash; </p></li>
<li><p>run <code>bitcoin-cli getblock &lt;hash&gt;</code> to get the block.  Note the <code>time</code> field</p></li>
<li><p>run <code>date -ud @&lt;time&gt;</code> to convert the time into human readable UTC, the same as used in debug.log.</p></li>
</ul></li>
<li><p>Use <code>bitcoin-cli</code> to run RPCs in an every-minute cron job to log additional information.  An example cron job might be, <code>* * * * * { date -u ; bitcoin-cli getnetworkinfo ; } &gt;&gt; getnetworkinfo.log</code></p></li>
</ul>

CC BY-SA 3.0
2015-01-13T12:18:04.667Z
Hi David, I forgot one point. The nodes provide RPC request service, probably one time RPC request per second. I set the rpc threads number 20. Is there something wrong? The debug log seems correct. Thank you very much.
Eleven
CC BY-SA 3.0
2015-01-13T15:58:03.460Z
As long as the computer you're using has an appropriate amount of resources, setting RPC threads to 20 and handling 1 request per second should not interfere with block downloading.
David A. Harding
CC BY-SA 3.0
2015-01-13T03:55:42.140Z
2015-01-13T03:55:42.140Z
David A. Harding
<p>I ran 6 or 7 bitcoinds with version 0.93 on CentOs. I used the default configuration on all of them. Sometimes I found one or two fell behind the others. And I need restart them, then they would work. I don't where is wrong, or there is some problem on the 0.93 version. Do I need update to the 0.10 version? When will the official 0.10 release. Thank you very much.</p>

CC BY-SA 3.0
2015-01-13T10:00:05.480Z
Are you running 6-7 bitcoind's on the same computer?
Nick ODell
<bitcoind>
Bitcoind blocks fell behind sometimes
Eleven
# Bitcoind blocks fell behind sometimes

(Asked by: username_0 on 2015-01-13)

I ran 6 or 7 bitcoinds with version 0.93 on CentOs. I used the default configuration on all of them. Sometimes I found one or two fell behind the others. And I need restart them, then they would work. I don't where is wrong, or there is some problem on the 0.93 version. Do I need update to the 0.10 version? When will the official 0.10 release. Thank you very much.

**Tags:** bitcoind

> **Comments:**
> **username_1**: Are you running 6-7 bitcoind's on the same computer?  

---

## 1 answers

### Answer by username_2 on 2015-01-13. Score: 3 | Accepted answer

1. **"Is there a problem with 0.9.3 that causes it to fall behind?** That's a serious problem for the network, but I haven't heard anyone else report it. If you debug it and discover that it's Bitcoin Core's fault, please [report it](https://github.com/bitcoin/bitcoin/issues/new). However, here are a few common reasons for problems:

   * **Insufficient resources:** if you're running Bitcoin Core on an underpowered VPS, Raspberry Pi, or other marginal hardware, you'll get all sorts of strange problems. I recommend a minimum of 1 gigabyte memory for a full node.
   * **Hardware problems:** bad memory, failing disks, and especially CPU overheating issues can cause your node to stop working or fail validation of a block.
   * **Suspend/Hibernate issues:** when restoring from suspend/hibernate on Linux, my nodes sometimes take a long time to reestablish connections and start downloading blocks, meaning my node looks like it has fallen behind for awhile.
   * **Clock issues:** if the clock on a computer falls behind real time by more than about 2 hours, it may not accept the most recent blocks.
2. **"Do I need to update to 0.10.0?"** Right now 0.10.0 is in the Release Candidate (RC) phase, which is the last testing phase. If you'd like to help test, feel free to upgrade. But if you're relying on Bitcoin Core behaving correctly, staying on most recent released version (0.9.3) is advised.
3. **"When will 0.10.0 be released?** When the developers think it has been well tested, and not a minute earlier. I know major software companies often release software on a set schedule, but they do it by holding back (hopefully) release-quality software. Open source doesn't work that way---everyone can see the source code, so you either release when it's ready or someone else releases it for you. :-)

---

## Debugging Tips

I highly recommend that you try to find out what causes your nodes to behave incorrectly or you're likely to have the same problem on 0.10.0 that you have on 0.9.3. Here are some quick tips:

* Check `$HOME/.bitcoin/debug.log` for any warnings or errors. If you can't figure out any messages using a web search, feel free to ask here.
* Start bitcoind with `-debug` to log additional information. Note, this will make your log file grow in size faster than normal, and it will inhibit shrinking the logfile on startup for as long as you use it.
* If you only rarely check your nodes, scanning the whole log might be hard. I suggest starting at the time indicated in the header of the old block you're stuck on. For example, if you're stuck on block 330,000,

  + run `bitcoin-cli getblockhash 3330000` to get the block's header hash;
  + run `bitcoin-cli getblock <hash>` to get the block. Note the `time` field
  + run `date -ud @<time>` to convert the time into human readable UTC, the same as used in debug.log.
* Use `bitcoin-cli` to run RPCs in an every-minute cron job to log additional information. An example cron job might be, `* * * * * { date -u ; bitcoin-cli getnetworkinfo ; } >> getnetworkinfo.log`

> **Comments:**
> **username_0**: Hi username_2, I forgot one point. The nodes provide RPC request service, probably one time RPC request per second. I set the rpc threads number 20. Is there something wrong? The debug log seems correct. Thank you very much.  
> **username_2**: As long as the computer you're using has an appropriate amount of resources, setting RPC threads to 20 and handling 1 request per second should not interfere with block downloading.  

---

