Top of local chain is empty

PoW Mining AE
1

Hello all, I downloaded Epoch v0.23.0 and followed the instructions in the docs directory to install, configure and run it (though I didn’t use different ports for in/external, i.e. everything uses 301x, specifically 3013 for http). But even after letting Epoch run overnight, curl http://127.0.0.1:3013/v2/blocks/top always returns an empty response.

The epoch_mining.log seems to indicate the miner is running ok:

2018-10-08 14:48:33.806 [info] <0.1235.0>@aec_conductor:start_mining:643 Starting mining
2018-10-08 14:48:43.137 [info] <0.1235.0>@aec_conductor:start_mining:643 Starting mining
2018-10-08 14:48:52.308 [info] <0.1235.0>@aec_conductor:start_mining:643 Starting mining

And the mean30s-generic process also runs and uses lots of CPU.

But maybe these entries from epoch.log indicate some problem?

2018-10-08 14:35:01.888 [debug] <0.1234.0>@aec_block_generator:handle_info:99 ignored event top_changed
2018-10-08 14:35:01.889 [debug] <0.1234.0>@aec_block_generator:handle_cast:70 stop_generation
2018-10-08 14:39:46.797 [debug] <0.1234.0>@aec_block_generator:handle_info:99 ignored event top_changed
2018-10-08 14:39:46.798 [debug] <0.1234.0>@aec_block_generator:handle_cast:70 stop_generation
2018-10-08 14:46:37.460 [debug] <0.1234.0>@aec_block_generator:handle_info:99 ignored event top_changed
2018-10-08 14:46:37.460 [debug] <0.1234.0>@aec_block_generator:handle_cast:70 stop_generation

This keeps going on like this…

1 Like
2

What’s the output of curl -v http://127.0.0.1:3013/v2/blocks/top?
What’s the output of netstat -nltp | grep beam ?
Can you also post your epoch.yaml ?

3 Likes
3 
goldmund:aenode babarr$ curl -v http://127.0.0.1:3013/v2/blocks/top
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 3013 (#0)
> GET /v2/blocks/top HTTP/1.1
> Host: 127.0.0.1:3013
> User-Agent: curl/7.61.0
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< content-length: 0
< date: Mon, 08 Oct 2018 15:17:30 GMT
< server: Cowboy
< 
* Connection #0 to host 127.0.0.1 left intact
goldmund:aenode babarr$

netstat -nltp | grep beam doesn’t work because I’m on MacOs which doesn’t support -p. However maybe this helps:

goldmund:aenode babarr$ sudo lsof -n -i4TCP -P | grep LISTEN|grep beam
beam.smp  15357 babarr   35u  IPv4 0x3531eb27a9e004eb      0t0  TCP *:54370 (LISTEN)
beam.smp  15357 babarr  218u  IPv4 0x3531eb27d1887b8b      0t0  TCP *:3015 (LISTEN)
beam.smp  15357 babarr  226u  IPv4 0x3531eb27ad2a4b8b      0t0  TCP *:3013 (LISTEN)
beam.smp  15357 babarr  227u  IPv4 0x3531eb27d0b157ab      0t0  TCP 127.0.0.1:3013 (LISTEN)
beam.smp  15357 babarr  228u  IPv4 0x3531eb27ad1b4b8b      0t0  TCP 127.0.0.1:3014 (LISTEN)
beam.smp  15357 babarr  229u  IPv4 0x3531eb27c5e4d4eb      0t0  TCP *:3014 (LISTEN)
goldmund:aenode babarr$

epoch.yaml:

sync:
    port: 3015
    external_port: 3015 

keys:
    dir: generated_keys
    password: "(hidden)"

http:
    external:
        port: 3013 
    internal:
        port: 3013

websocket:
    internal:
        port: 3014
    channel:
        port: 3014 

mining:
    beneficiary: "ak_2CPLTqxLVXLkjuEzLJEkDYD5Cxdn3DQ5EiqpAktJg3rH7EcdCB"
    autostart: true

chain:
    persist: true
    db_path: ./my_db

(Edit show output of curl -v... instead of just curl....)

1 Like
4

@doktorbastian.chain I think the issue is that you’re trying to use the same ports for http internal/external and websocker internal/channel. The sync configuration is OK tho.

Please try using separate ports:

http:
    external:
        port: 3013 
    internal:
        port: 3113

websocket:
    internal:
        port: 3114
    channel:
        port: 3014

Explanation:
The default value of http.external.listen_address is 0.0.0.0
The default value of http.internal.listen_address is 127.0.0.1

So your current configuration is effectively parsed as:

http:
    external:
        port: 3013
        listen_address: 0.0.0.0
    internal:
        port: 3113
        listen_address: 127.0.0.1

As seen on your lsof output it creates two separate listeners. The curl request you’re sending is to 127.0.0.1 which is the internal API listener, where there is no blocks/top endpoint.

If you try sending curl request to some other IP address of the same machine it should success .

The same applies for websocket configuration.

3 Likes
5

Oh, I wasn’t aware that it would listen on both external and internal ports. From this paragraph in the configuration.md doc:

Please notice that, if your node is behind a firewall, you need to open a TCP port in your firewall ( sync > port parameter) and map that port to the one the node actually listens on ( sync > port parameter - the same). If the publicly available port needs to be different from the internal one, you need to set ( sync > external_port ) accordingly.

I would have thought this means that one should forward the external port on the router/firewall to the internal port on the local machine? And because it says

If the publicly available port needs to be different from the internal one

I would have thought that means that they can be the same…

Anyway, I changed my epoch.yaml as you suggested and forwarded my router’s ports 3013-3015 to my local machine’s ports 3013-3015, i.e. to epoch’s external ports, contrary to what is stated in configuration.md.

This worked now:

goldmund:aenode babarr$ curl http://127.0.0.1:3013/v2/blocks/top
{"beneficiary":"ak_tjnw1KcmnwfqXvhtGa9GRjanbHM3t6PmEWEWtNMM3ouvNKRu5","hash":"kh_8mm9DfrFGcrCgzV5nNJ4WiGyHMxAELBjkhWafHDk3NzPDeBc8","height":5816,"miner":"ak_26Q4P9ob21bfsjmvBKiqDWcPbCpN2FGUJsLrDBi9RerUy8Zixb","nonce":16475541129494396609,"pow":[7213523,7527833,13797929,28487979,51111751,64330320,69700397,71326689,75722948,81775230,95865506,122791794,133015670,141235708,184730631,186955605,189856040,208251689,216154921,253318606,257077551,275656991,275743378,289933807,294550459,313595091,338755813,349420996,369581370,390368391,411368086,418818452,436574514,456130956,467094188,470980849,475466256,485903027,492830814,502600778,507709808,535868928],"prev_hash":"kh_2Rru4TNXFAyBa4Z3gTwwikcV8WqTYLn3w11dVJHNFcjQ9quzHf","prev_key_hash":"kh_2Rru4TNXFAyBa4Z3gTwwikcV8WqTYLn3w11dVJHNFcjQ9quzHf","state_hash":"bs_9VK78dHtGXQBPUKbmoRX2dEsVmYAS1LQHghRV23rTHcJ5xx35","target":538260967,"time":1539076336847,"version":24}

Also note that I tried setting

sync:
    port: 3115
    external_port: 3015

to be consistent with the other ports, but this made it listen only on 3115 on localhost as well as external interfaces. So the sync: external_port parameter seems to be ignored completely?

1 Like
6

The paragraph you’re referring to is about sync ports only and it’s correct (it could be improved tho).

sync.port is the actual port used to bind the listener. However, if the node is behind a firewall/SNAT, and for some reason you cannot DNAT/open (forward) that same port - only then you need different sync.external_port option. Otherwise keep it the same.

The sync.external_port does not bind any listener, it’s only used in the sync protocol when the node own address is announced. So instead of announcing the listener port sync.port the node announces that sync.external_port, this is effectively the port where the node is reachable by other nodes in the network.

I personally find this option not so useful and as we can see a bit confusing :slight_smile:

I hope the clears the question for you.

3 Likes
7

Yes, thanks, it is clear now. I’ll see if I can get around to try and make the descriptions in configuration.md clearer.

3 Likes