ot4i / iib-docker

Eclipse Public License 1.0
63 stars 115 forks source link

MQTT not starting up when running on Windows 10 #37

Closed joebuckeye closed 6 years ago

joebuckeye commented 6 years ago

When I run this container using Docker for Windows on Windows 10 the MQTT process is failing to start.

Here are the contents of the file /var/mqsi/components/MYNODE/stderr:

Sourcing profile

2017-10-03 13:50:44.627996 AdminAgent started. Process ID : 120 Broker is: MYNODE 1507038646: mosquitto version 1.4 (build date 2015-02-18 23:32:10+0000) starting 1507038646: Config loaded from /var/mqsi/components/MYNODE/config/MYNODE. 1507038646: Opening ipv4 listen socket on port 11883. 1507038646: Opening ipv6 listen socket on port 11883. 1507038646: Error: Cannot assign requested address 1507038653: mosquitto version 1.4 (build date 2015-02-18 23:32:10+0000) starting 1507038653: Config loaded from /var/mqsi/components/MYNODE/config/MYNODE. 1507038653: Opening ipv4 listen socket on port 11883. 1507038653: Opening ipv6 listen socket on port 11883. 1507038653: Error: Cannot assign requested address

When I run the container on a Linux node MQTT starts up ok.

Any hints for what might be causing this issue?

bthomps commented 6 years ago

Hi Joe,

It's possible (likely?) that the diference in behaviour you're observing between running the container on Windows 10 versus running on Linux is down to your docker image inheriting its network configurations from your host. If so, then it could be the case that you don't have an ipv6 networking stack available. If this is the case then by default one of the internal IIB components (our MQTT implmentation - which as you can see in your log snippet is based on mosquitto) will be attempting to bind localhost to both ipv4 and ipv6, and we will fail to find ipv6 and hence cause the MQTT process to fail to start. If this is the problem then there are several ways you could fix this.

  1. You could change /etc/hosts to not map localhost to ip6 ... when running Docker you might well not have sufficient privilege or desire to change this, so would advise not this one ...
  2. You could change IIB's configuration file /var/mqsi/components/MYNODE/config/MYNODE (alter "localhost" to "127.0.0.1")
  3. BEST OPTION IN MY OPINION. You can set the environment variable MQSI_MQTT_LOCAL_HOSTNAME=127.0.0.1 ... which causes IIB to disregard the setting in the file and use this value instead. I very recently made a change to the IIB Dockerfile to set this by default, so if you do a clone and build of the image then you might find everything now "just works" for you!

Cheers, Ben

joebuckeye commented 6 years ago

Thanks Ben. It's working now.

I think I happened to pull the repo after you added MQSI_MQTT_LOCAL_HOSTNAME to the iib_manage.sh script which was not working and gave the output I posted above. I then saw you made a change to move that declaration to the Dockerfile and repulled it and rebuilt and now it is working.

My only question would be why the line was added so early in the Dockerfile? Is this variable needed during the install or just before it is run (ie iib_manage.sh)? I'm asking because rebuilding it made me re-pull the install media from IBM again (which takes some time) and if it isn't needed until run time then if it was added before then many of the intermediate layers wouldn't need to have been rebuilt and be much quicker.

joebuckeye commented 6 years ago

Also, what version of IIB was this "MQSI_MQTT_LOCAL_HOSTNAME" functionality added?

I tried it with version 10.0.0.7 and it didn't appear to work. I'm working on getting a more recent version accessible to our internal Docker repo.

bthomps commented 6 years ago

The environment variable was added in 10.0.0.10 The environment variable is not needed during the install - to avoid rebuild of intermediate layers we will move it lower (PR submitted, will approve shortly)

s-rogers commented 6 years ago

I believe this is resolved now, and the env variable is lower in the layer stack to help anyone who has already downloaded the binaries