Bitcoin Forum
May 21, 2024, 11:40:45 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: bitcoind requires restart to continue syncing  (Read 6118 times)
bigbeninlondon (OP)
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500



View Profile
May 09, 2014, 11:41:26 AM
Last edit: May 09, 2014, 12:12:21 PM by bigbeninlondon
 #1

So here's my problem.  I've got bitcoind running as a daemon and it syncs fine for a while, and then slows down and stops syncing, and then I have to restart it to get it going again.

A couple of questions.

I see this sometimes in my debug.log before it stops:


Code:
2014-05-09 11:23:39 ERROR: AcceptToMemoryPool : nonstandard transaction: scriptsig-non-canonical-push
2014-05-09 11:23:50 ERROR: AcceptToMemoryPool : nonstandard transaction: dust


Are these potential culprits?

Second,

I found a script that modifies tc rules to restrict bandwidth.  I ran them, but then later ran
Code:
tc -s qdisc ls dev eth0
so it should be cleared, right?

Third,

My distro came with berkeley db 5.3, and won't install 4.8, so I had to compile with --with-incompatible-db flag.  Would this make a difference?

Fourth,

This is a new install because my previous install got messed up (don't chown -R on /usr/bin!).  I had my .bitcoin folder backed up, including the blockchain.  It looks like the new compile of bitcoind didn't like the old blocks, and so is replacing them with new blocks from sync.  Is there something that could have  happened here to cause my problem?

Finally, I discovered that my swap partition hadn't been mounted and had no swap space.  I've re-enabled it and restarted bitcoind but I'm still having problems.

What else can I check?  I'm on Ubuntu 14.04 server

Edit:

Also, why do I sometimes see long strings of
Code:
 ORPHAN BLOCK 112, prev=000000000000000033cac1b48e35a41c3834b7678269a5a5e8d3e61b618a6dca

in my debug.log?

Are there really that many orphaned blocks?

Edit2:

Here's some more errors I get a bunch:

Code:
2014-05-09 12:08:22 ProcessBlock: ACCEPTED
2014-05-09 12:08:24 ERROR: CheckTransaction() : vin empty
2014-05-09 12:08:24 ERROR: AcceptToMemoryPool: : CheckTransaction failed
2014-05-09 12:08:24 Misbehaving: 93.77.226.90:8333 (0 -> 10)
2014-05-09 12:09:13 ResendWalletTransactions()
2014-05-09 12:09:13 Relaying wtx 3e1a26f1814be4146b6574924231d4c0f7fd285660a5d6c001c8d64cff58dc9d
2014-05-09 12:10:12 socket recv error 104
dserrano5
Legendary
*
Offline Offline

Activity: 1974
Merit: 1029



View Profile
May 09, 2014, 03:52:27 PM
 #2

I've got bitcoind running as a daemon and it syncs fine for a while, and then slows down and stops syncing, and then I have to restart it to get it going again.

It stopped once on me when there were a few blocks left to be downloaded (can't recall but less than 15 for sure). Upon discovery of a new block elsewhere in the network, my instance fetched the remaining ones as usual and became synchronized.


I see this sometimes in my debug.log before it stops:

Code:
2014-05-09 11:23:39 ERROR: AcceptToMemoryPool : nonstandard transaction: scriptsig-non-canonical-push
2014-05-09 11:23:50 ERROR: AcceptToMemoryPool : nonstandard transaction: dust


Are these potential culprits?

No, I don't think so. They are just notifications of rubbish spotted in the network.


I found a script that modifies tc rules to restrict bandwidth.  I ran them, but then later ran
Code:
tc -s qdisc ls dev eth0
so it should be cleared, right?

"it should be cleared" isn't clear Tongue. Anyway, that command should list something, otherwise there's no traffic shaping in action. I can show you my script to shape my traffic from tor and bitcoind.


My distro came with berkeley db 5.3, and won't install 4.8, so I had to compile with --with-incompatible-db flag.  Would this make a difference?

That wallet won't work on older versions of bitcoin core. Besides that, you should be fine.
bigbeninlondon (OP)
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500



View Profile
May 09, 2014, 05:15:13 PM
 #3

I've got bitcoind running as a daemon and it syncs fine for a while, and then slows down and stops syncing, and then I have to restart it to get it going again.

It stopped once on me when there were a few blocks left to be downloaded (can't recall but less than 15 for sure). Upon discovery of a new block elsewhere in the network, my instance fetched the remaining ones as usual and became synchronized.


Ok, so it may just be hung up on a given node?  I left it going all night and it just listed like 300 orphan blocks, and no new accepts.  Upon restart, accepts started rolling in at the rate of about 6 per second. 


I see this sometimes in my debug.log before it stops:

Code:
2014-05-09 11:23:39 ERROR: AcceptToMemoryPool : nonstandard transaction: scriptsig-non-canonical-push
2014-05-09 11:23:50 ERROR: AcceptToMemoryPool : nonstandard transaction: dust


Are these potential culprits?

No, I don't think so. They are just notifications of rubbish spotted in the network.

Ok, so I can ignore those

I found a script that modifies tc rules to restrict bandwidth.  I ran them, but then later ran
Code:
tc -s qdisc ls dev eth0
so it should be cleared, right?

"it should be cleared" isn't clear Tongue. Anyway, that command should list something, otherwise there's no traffic shaping in action. I can show you my script to shape my traffic from tor and bitcoind.
I meant that that command should clear any traffic shaping/throttling rules, and my connection should be wide open.  I even restarted the server to make sure that no rules were in place.  I can throttle/shape once my install is stable.

My distro came with berkeley db 5.3, and won't install 4.8, so I had to compile with --with-incompatible-db flag.  Would this make a difference?

That wallet won't work on older versions of bitcoin core. Besides that, you should be fine.


Ok, I just don't know why I get a good bit of the way through, and then just completely stop for hours.  It doesn't make sense and I can't find the culprit and I'm at a loss for what to do.  My next step is probably to just install from the ppa and see if that fixes it.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!