Unresponsive Node with Error - Connected to Self

Question

Hi

I'm running a couple of multichain nodes on Azure and have been seeing this issue recently.
 

connected to self at 172.18.0.1:50940, disconnecting

 

Can you explain what scenarios would cause this (assuming it's an environment issue) so that I can resolve??

 

Thanks

 

Marty 

Comments

Where are you seeing this message? In the debug log?

---

yes, in the debug log.  When I bounce the docker image it all behaves as expected.

Answer 1

This may happen when you run several nodes on the same server. It is not an error. Node can accidentally connect to itself, in this case it disconnects immediately.

Please let us know if you don't run several nodes on the same server.

Comments

Multichain is the only process running on this server albeit it's inside a docker container?

---

But do you run several MultiChain nodes having the same IP address (for example, using different -datadir, -port, -rpcport)?

This may happen when more than one node have IP address 172.18.0.1.

---

Another (much simpler and more likely) case when this can happen:

if multichaind node uses itself as seed, i.e. you run

multichaind <chain-name>@172.18.0.1:<node-port>

where <node-port> is the port of the node itself.

When chain is initialized (either it was created by this node or started successfully once with the seed), there is no need in specifying seed again, you may run simply

multichaind <chain-name>

Anyway, it is not error, you can ignore it.

---

My setup is 3 nodes each on their own virtual machine running within docker.  Two are seeded to the first via it's private ip, but all three share the same public ip on a cloud load balancer using different ports via NAT rules.

I guess there's the possibility the docker ip on each machine is the same even though I peer via the VM private IP address?

I'm not in the office at the minute so I'll keep an eye on it as it's happened a couple of times.  My concern is that when it does occur the node is unresponsive on it's rpc port and I need to bounce it?

Marty

---

A bit more....here's a snippet of the ifconfig for the azure node:

br-409b4070a44a Link encap:Ethernet  HWaddr 02:42:f4:f7:c8:c0
          inet addr:172.18.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:f4ff:fef7:c8c0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9667 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9725 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:742791 (742.7 KB)  TX bytes:836219 (836.2 KB)

docker0   Link encap:Ethernet  HWaddr 02:42:95:64:6f:ba
          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:0d:3a:27:6a:01
          inet addr:10.0.0.10  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20d:3aff:fe27:6a01/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1532456 errors:0 dropped:7 overruns:0 frame:0
          TX packets:1584729 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1538608491 (1.5 GB)  TX bytes:283232778 (283.2 MB)

The message from multichain is showing it's finding itself on the first config: br-409b4070a44a

it's logging -> 2017-07-20 18:18:03 connected to self at 172.18.0.1:37016, disconnecting

Now the node seems to be OK.....I hit it with a few things and it's behaving, so as you said, probably nothing to worry about.  When I checked what peers it knows about, this ip is not one of them so I'm happy to ignore this but it's like a itch I can't scratch :)

Marty

---

First of all, this message has nothing to do with RPC requests. It is about connection between nodes.

If you have RPC request stuck, please run multichaind with -debug=mcapi. This will log all RPC requests and we can learn where exactly it was stuck.

Regarding this innocent message, are you sure you start that "seed" node with

multichaind <chain-name>

and not with

multichaind <chain-name>@<ip>:<port>?

---

OK Michael, I'm just trying to provide more information to get a sense if there is an issue or not.  I think we can probably just leave this now.

I have a call scheduled with Gideon for the week after next to discuss this project and a couple of others.  I'll raise any concerns with him directly.

Thanks for the help

Marty

---

This is happening to me as well. It my not be a problem, but it is at least a waste of resources. Also, it is cycling through hundreds of port numbers. In my case, it is also running in Docker. There is only one server running. I do not include the IP on the multichaind call.

---

MultiChain has database of peers (to maintain p2p communication). From time to time it tries to connect to these peers. Normally it should not connect to itself (because node doesn't store its own address in the database), but if node doesn't have permanent IP it may happen.

Nodes should make these failed connection attempts less frequently with time and eventually "forget" this IP.

---

Hey Michael,

That all makes perfect sense, but I've seen the same behaviour mentioned by @fierozen.  It's almost like it's trying to discover nodes and while the peer count is low (say 2 nodes), it occasionally does this cycle through trying other ports.  

Marty

---

MultiChain tries to connect to all peers it saw, including those running on the same IP with different port, even if connection was established only once.

IP:port stored in the database is extracted from the "version" message, created by connecting peer. So if you run unmodified version of MultiChain, the port can be either default chain port or the value specified in -port runtime parameter.

If it is not a case, -debug=addrman may help to diagnose the problem.