Unable to bind (to port)
Unable to bind any endpoint for RPC server
It is a quite common error for community companies of every kind. The commonest causes are that there’s already one other service sure to the port (8332 on this case) or that the consumer lacks permissions.
You may verify what service is sure to port 8332 utilizing one thing just like the netstat -anp command.
Errors with binding
The next examples are on Home windows however the Linux instructions have solely minor variations (e.g. Use grep as a substitute of findstr)
this is one method to verify what present course of is utilizing the port
C> netstat -anb | findstr /N "bitcoin 8332"
63: [bitcoind.exe]
65: [bitcoind.exe]
67: [bitcoind.exe]
69: [bitcoind.exe]
70: TCP 127.0.0.1:8332 0.0.0.0:0 LISTENING
71: [bitcoind.exe]
132: TCP [::1]:8332 [::]:0 LISTENING
133: [bitcoind.exe]
The above tells you that bitcoind is already operating and it’s listening to the community at port 8332, ready for requests.
Testing RPC
You may check fundamental connectivity as follows
C> curl http://localhost:8332/
JSONRPC server handles solely POST requests
Observe that I intentionally do not ship credentials or a sound request. Nonetheless the bitcoind receives the request and tells me one thing about what it does not like. That proves the bitcoind HTTP service is working. I do not get a connection refused message from curl.
This is an instance that exhibits passing credentials and receiving an error message
C> curl -v -u consumer:cross -d '{"methodology":"getblockhash","params":[0],"id":1}' http://localhost:8332/
* Making an attempt 127.0.0.1:8332...
* Related to localhost (127.0.0.1) port 8332 (#0)
* Server auth utilizing Fundamental with consumer 'consumer'
> POST / HTTP/1.1
> Host: localhost:8332
> Authorization: Fundamental dG9kYXk6dGVtcG9yYXJ5
> Person-Agent: curl/8.0.1
> Settle for: */*
> Content material-Size: 39
> Content material-Sort: utility/x-www-form-urlencoded
>
< HTTP/1.1 500 Inner Server Error
< Content material-Sort: utility/json
< Date: Solar, 16 Jul 2023 14:27:47 GMT
< Content material-Size: 74
<
{"consequence":null,"error":{"code":-32700,"message":"Parse error"},"id":null}
* Connection #0 to host localhost left intact
On this case there’s a HTTP 500 error as a result of bitcoind was unable to parse knowledge.
You will want to specify -v to remember to see the HTTP error messages, however it is not wanted after getting JSON responses working. We are able to drop the -v choice to scale back the litter
I modified the quoting from single to double quotes. You should not have to do that on Linux, it’s a Home windows characteristic:
C> curl -u consumer:cross -d "{"methodology":"getblockhash","params":[0],"id":1}" http://localhost:8332/
{"consequence":null,"error":{"code":-28,"message":"Beginning community threads…"},"id":1}
Now bitcoind does not have issues parsing knowledge however says it’s nonetheless busy initialising.
We are able to ask it a query that does not rely on blockchain state and many others
C> curl -u consumer:cross -d "{"methodology": "uptime", "params": []}" http://localhost:8332/
{"consequence":2063,"error":null,"id":null}
bitcoind experiences it has been operating for 2063 seconds
C> curl -u consumer:cross -d "{"methodology": "uptime", "params": []}" http://localhost:8332/
{"consequence":2427,"error":null,"id":null}
Now it’s 2427 seconds since bitcoind began.
If I swap to WSL for no specific cause aside from to attempt an RPC name utilizing Linux, bitcoind is has completed initialising and may reply questions on blockchain knowledge
$ curl -u at present:momentary -d '{"methodology":"getblockhash","params":[0],"id":1}' http://localhost:8332/
{"consequence":"000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f","error":null,"id":1}
On my PC, with many different processes operating, this question can take a number of minutes, so that you may want to regulate shopper timeouts.
