clamd hangs/fails silently while downloading blockchain

[abmohan]

clamd occasionally fails silently while downloading the blockchain, requiring the process to manually be killed and restarted.

It would be ideal if whatever is causing the process to stall would instead throw an exception that killed the process. This would allow it to be monitored and automatically restarted by a linux tool such as monit.

[abmohan]

I raised this in the IRC channel and apparently it's a known issue, so I thought I'd create an issue to help track it. I'm happy to chip in towards a fix, if someone can help me narrow down what might be causing the problem.

[ClamProject]

If you'd like to take a stab at it, contact creativeCLAM or xploited on IRC via PM.

[abmohan]

Will do. Thanks

[ClamProject]

Some of the inventory messages, likely involved with hashhighblock, are requesting duplicate, already sync'd/possessed blocks. This causes existing nodes to apply misbehavior and ban the peer for jumping backwards in height. One of the problems with fixing this is these inventory messages are often triggered by the sending node, not the requesting node. At the same time, it is difficult to simply ignore these messages because although they could sometimes represent a jump backwards and duplication, they could also sometimes represent a fork which needs to begin backwards in height.

Just a 30 second riff-raff of some of the problem we've observed :)
Again, if you're serious about tackling the problem we have detailed logs and such, stop by #clams :)

[tryphe]

If you're interested, you should checkout this branch, it should help, and it might be nice to have some feedback. I haven't tried anything other than syncing with it (per xploited: "im not sure i would even use that branch honestly"), but it seems to fix the backwards issue. Personally, on my connection, I've never had it stop me from syncing, so I'm only partially familiar with this issue, but I don't see any duplicate block messages anymore.

git clone -b 2.0.0-rc1 https://github.com/nochowderforyou/clams/

To avoid confusion from running multiple clients, I run make/make install as usual, and then rename the binary in /usr/local/bin to something like clamd-2.0.0-rc. Here's a ~/.bashrc macro you can use along with that to avoid insanity. It sets a hard path to a new configuration and data directory to be used, that way you can run it along muitiple builds of clamd. You can also set the path in the config file instead of the bashrc macro.

alias cc2='clamd-2.0.0-rc --conf=/home/user/.clam/2.0.0-rc/clam.conf --datadir=/home/user/.clam/2.0.0-rc'

Then tell bash to parse bashrc again: source ~/.bashrc

Now just make a clam.conf in the data directory from the above macro, and it's good to run. Here's the one I used for testing:

testnet=0
listen=0
server=1
daemon=1

rpcuser=clamrpc
rpcpassword=super_sekret_password

addnode 74.207.230.61

Now you can use cc2 to start the daemon and cc2 getinfo to parse the info. Another thing to keep in mind is that you should close your other non-testnet clam daemons because they could be getting the new client banned if they are causing too many requests.

[ClamProject]

Saw that you had stopped into #clams.
Need to be patient and loiter a bit next time until someone sees :)

[tryphe]

Another thing to keep in mind is that you should close your other non-testnet clam daemons because they could be getting the new client banned if they are causing too many requests.

I was wrong about this, a bit. Add addnode 74.207.230.61 to the config and you will get a node that is running the rc branch, for which the ban threshold was fixed(among other things) and this node won't ban you.

[l0rdicon]

fixed in 2.1.0