Bitcoiner fails to connect #9600

Describe the issue

Since version 0.13.2 a popular client (Bitcoiner on Android) fails to connect to the daemon via the HTTP-based RPC interface.

The server receives the initial getinfo POST request:

Received a POST request for / from XXX.XXX.XXX.XXX:AAAA 2017-01-20 16:53:46 ThreadRPCServer method=getinfo

But then the client side on Android seems to time out:

01-20 17:53:56.316 26855 26855 W bitcoiner: RPC call failed 01-20 17:53:58.503 2397 3033 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=net.lwi.bitcoiner/.Main bnds=[360,406][477,579] (has extras)} from uid 10023 on display 0

(time skew on the server side being UTC vs. CET).

Can you reliably reproduce the issue?

Start server and client and wait.

If so, please list the steps to reproduce below:

1. See above

Expected behaviour

Client should display wallet contents.

Actual behaviour

Client seems to time out.

What version of bitcoin-core are you using?

List the version number/commit ID, and if it is an official binary, self compiled or a distribution package such as PPA. 0.13.2-3 (on an armv7h board, Arch community/bitcoin-daemon 0.13.2-3 package)

Machine specs:

• OS: Arch
• CPU: dual-core armv7h
• RAM: 2GB
• Disk size: 512 GB
• Disk Type (HD/SDD): USB

Any extra information that might be useful in the debugging process.

This is normally the contents of a debug.log or config.log file. Raw text or a link to a pastebin type site are preferred.

debug.log: http://pastebin.com/ESQYSkWk

More than happy to provide more info for both server and client; just let me know what you need.

BTW: not sure where the RPC port failure message comes from as the port is open on the machine.

Hmm, well there isnt much to go on here (maybe someone else will chime in with RPC changes in 0.13.2, but I'm not aware of any). To confirm, this started with 0.13.2, but did not appear in 0.13.1?

If you could provide any more useful debug from the RPC client (ie does it report error codes in some way?) that would be useful, otherwise a tcpdump network capture (hopefully anonymized to only include the one port/IP, with a different rpcuser/password than normal and only local IPs) might be useful.

RESTful getinfo works fine on my ARM instance. It may be that your client time-out's quickly or that the RESTful responses a bit slower than before. You should probably use curl to demonstrate this is a Core problem, and separately work on the timeout issue with your client app maker. If a 3rd party client fails, that doesn't necessarily mean the server has a bug.

After more research, I discovered something close to a root cause for this: the server never leaves the "loading block index". Hence the RPC layer (server.cpp) never executes a "SetRPCWarmupFinished" and the Android client times out.

This is confirmed by the status -28 from the command line (bitcoin-cli) and the qt interface.

Thought? Is my local copy of the blockchain corrupt?

What does the end/beginning after restart of your debug.log look like?

On January 24, 2017 6:06:46 AM EST, monochromec notifications@github.com wrote:

After more research, I discovered something close to a root cause for this: the server never leaves the "loading block index". Hence the RPC layer (server.cpp) never executes a "SetRPCWarmupFinished" and the Android client times out.

This is confirmed by the status -28 from the command line (bitcoin-cli) and the qt interface.

Thought? Is my local copy of the blockchain corrupt?

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/issues/9600#issuecomment-274774083

Here you go: http://pastebin.com/ueTwQv4w

Looks like you're running code from the current master branch:

2017-01-24 11:43:58 Bitcoin version v0.13.99.0-23281a4dc

which corresponds to this commit from 10 days ago: https://github.com/bitcoin/bitcoin/commit/23281a4dc3afc42a001346caec4dbb8193f0bb53

Your OP reported this was happening on 0.13.2. Does this issue repro on 0.13.2?

Hmmm....

Came from the distro repo (alarm):

Name : bitcoin-daemon Version : 0.13.2-3 Description : Bitcoin is a peer-to-peer network based digital currency - daemon Architecture : armv7h URL : http://www.bitcoin.org/ Licenses : MIT Groups : None Provides : None Depends On : boost-libs libevent miniupnpc zeromq Optional Deps : None Required By : None Optional For : None Conflicts With : None Replaces : None Installed Size : 4.26 MiB Packager : Arch Linux ARM Build System builder+xu3@archlinuxarm.org Build Date : Thu 19 Jan 2017 02:26:11 AM CET Install Date : Fri 20 Jan 2017 05:26:35 PM CET Install Reason : Explicitly installed Install Script : No Validated By : SHA-256 Sum

Maybe the packager got the version wrong?!?

That doesn't seem right...the bitcoin-daemon-0.13.2-3-armv7h.pkg.tar.xz I got from the arch mirrors has no ".99.0" string in the binary - it identifies itself as v0.13.2.0-0d719145b-dirty (which is, itself, somewhat concerning considering the regular arch one correctly identifies itself as "v0.13.2" and they have an identical PKGBUILD).

Pulled it from the community repo as the pacman info above states. Which mirror did you use?

Could you upload the pkg.tar.xz from /var/cache/pacman/pkg/bitcoin-daemon-0.13.2-3* somewhere?

Sure thing - here you go: www.monochromec.com/bitcoin-daemon-0.13.2-3-armv7h.pkg.tar.x

There's no end in that debug log.

After more research, I discovered something close to a root cause for this: the server never leaves the "loading block index

In other words, it likely hasn't started.

You may wish to check `which bitcoind` to find which binary you are running - the bitcoind binary in the package you uploaded identifies itself as "v0.13.2.0-0d719145b-dirty" not "v0.13.99.0-23281a4dc"

/usr/bin/bitcoind @unsystemizer: that was my assumption too. The question is: why is it looping through the init loop w/o end and how can this be fixed?

Well, maybe you can debug=1 and post the entire log, that's why I mentioned we'd need to know from the logs that at some point it's ready (service started up and RPC server ready for queries). If it can't start, it's not an RPC-related bug. It may be another bug, but that'd be another story, although I've got several 0.13.2's on armhf with RPC server running with no issues.

I think we are getting somewhere:

http://pastebin.com/KEsH71b7

This morning the server crashed after catching up on the blockchain for nearly 10 hours.

How can I fix this? Do I have to download the complete blockchain again (perhaps speeding this up via a bootstrap torrent) or is there a quicker solution?

2017-01-25 01:14:38 Error: Incorrect or no genesis block found. Wrong datadir for network?

If you stopped it before while it was reparsing the blockchain (after the upgrade from 0.12.* it has to be done once), maybe you corrupted the blockchain. You can see the reindex command or copy another good copy from somewhere - there are many how-to's and the docs explain it well. Of course you can also make a backup or snapshot of the current blockchain (and wallet) just in case. But as far as this RPC server issue is concerned, I think you could close it because it unfortunately is what I suspected (RPC server doesn't start).

Closing this issue due to further RCA.