Support for alpha 29? about multichain-explorer

[gidgreen]

Can you post the output of getruntimeparams?

[mgeeforce]

hmmmm

guild1: getruntimeparams
{"method":"getruntimeparams","params":[],"id":1,"chain_name":"guild1"}

{
    "port" : 4291,
    "reindex" : false,
    "rescan" : false,
    "txindex" : true,
    "autocombineminconf" : 1,
    "autocombinemininputs" : 50,
    "autocombinemaxinputs" : 100,
    "autocombinedelay" : 1,
    "autocombinesuspend" : 15,
    "autosubscribe" : "",
    "handshakelocal" : "1BGp32TEHtXqXDvsjztNqzMWZqTCanKEMPtReS",
    "bantx" : "",
    "lockblock" : "",
    "hideknownopdrops" : false,
    "maxshowndata" : 16384,
    "miningrequirespeers" : true,
    "mineemptyrounds" : 10.00000000,
    "miningturnover" : 0.50000000,
    "lockadminminerounds" : 10,
    "gen" : true,
    "genproclimit" : 1,
    "mineblocksondemand" : false
}

So when I change the rpcport in multichain.conf to be 4291 multichain-explorer works.

[gidgreen]

OK, great, so I'm closing this issue.

[mgeeforce]

Sorry forget the last line of my last post. This problem still exists when trying to rebuild the explorer sqlite db. Strangely, if you change the rpcport in multichain.conf to 4291 without restarting multichain - it will rebuild the db by connecting over port 4291. So it looks like explorer can only connect vi IPv4?

synergy@beechbone:~/multichain-explorer$ netstat -lp | grep multichain
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:4291            0.0.0.0:*               LISTEN      13900/multichaind   
tcp6       0      0 [::]:4290               [::]:*                  LISTEN      13900/multichaind   
tcp6       0      0 [::]:4291               [::]:*                  LISTEN      13900/multichaind   

I was reading this old thread regarding similar issues for clues: https://bitcointalk.org/index.php?topic=165336.0

[mgeeforce]

synergy@beechbone:~$ uname -a
Linux beechbone 4.8.0-26-generic #28-Ubuntu SMP Tue Oct 18 14:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Digging a little deeper this does seem to be related: maybe the Python client is defaulting to IPv4 - where no one is actually listening.

synergy@beechbone:~$ netstat -lp4 | grep multichain
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:4291            0.0.0.0:*               LISTEN      13900/multichaind   
synergy@beechbone:~$ netstat -lp6 | grep multichain
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp6       0      0 [::]:4290               [::]:*                  LISTEN      13900/multichaind   
tcp6       0      0 [::]:4291               [::]:*                  LISTEN      13900/multichaind   

I tried adding rpcallowip=127.0.0.1 (and restarting multichain) but it didn't make any difference.

[mgeeforce]

Forget all of the above. Sorry for wasting space. Regardless of what netstat says, "telnet -4 localhost 4290" which forces the connection on IPv4 totally works and proves that someone is listening on port 4290.

synergy@beechbone:~$ netstat -an | grep 4290
tcp        0      0 127.0.0.1:49884         127.0.0.1:4290          ESTABLISHED
tcp        0      0 127.0.0.1:49880         127.0.0.1:4290          TIME_WAIT  
tcp6       0      0 :::4290                 :::*                    LISTEN     
tcp6       0      0 127.0.0.1:4290          127.0.0.1:49884         ESTABLISHED
tcp6       0      0 127.0.0.1:4290          127.0.0.1:49882         TIME_WAIT  

Back to the drawing board.