bind-address parameter issue on 0.9

[beckettsean]

To issue from mailing list: https://groups.google.com/d/msgid/influxdb/455762cc-9669-4aa6-83ba-3df4e331dace%40googlegroups.com

---

I have issue after change "bind-address" parameter from "0.0.0.0" to particular IP (not localhost).
But unfortunatelly, influxdb can't run.
I don't know why influxdb still contact localhost not IP from bind-address

[srvr] 2015/04/24 13:35:06 GOMAXPROCS set to 2
[srvr] 2015/04/24 13:35:06 using configuration at: /etc/opt/influxdb/influxdb.conf
[srvr] 2015/04/24 13:35:06 influxdb started, version 0.9.0-rc27, commit c887dfe2a86ca7dc6a06710b6a787d37734a23b4
[srvr] 2015/04/24 13:35:06 Cluster server listening on 128.199.66.29:8086
[srvr] 2015/04/24 13:35:06 broker opened at /var/opt/influxdb/raft
[raft] 2015/04/24 13:35:06 Open: fsm: index=0
[raft] 2015/04/24 13:35:06 log pending: waiting for initialization or join
[raft] 2015/04/24 13:35:06 changing term: 0 => 1
[raft] 2015/04/24 13:35:06 log state change: stopped => leader (term=1)
[raft] 2015/04/24 13:35:06 leaderLoop
[raft] 2015/04/24 13:35:06 log initialize: promoted to 'leader' with cluster ID 9198811507380792097, log ID 1, term 1
[srvr] 2015/04/24 13:35:06 initialized broker: http://localhost:8086
[srvr] 2015/04/24 13:35:06 data node(0) opened at /var/opt/influxdb/db
[messaging] 2015/04/24 13:35:06 reconnecting to broker: url={http  <nil> localhost:8086 /messaging/messages index=0&streaming=true&topicID=0 }, err=Get http://localhost:8086/messaging/messages?index=0&streaming=true&topicID=0: dial tcp 127.0.0.1:8086: connection refused
[srvr] 2015/04/24 13:35:07 join: failed to connect data node: http://localhost:8086: Post http://localhost:8086/data/data_nodes: dial tcp 127.0.0.1:8086: connection refused
[srvr] 2015/04/24 13:35:07 join: failed to connect data node to any specified server

Regards,
--Rizal

[easyrasta]

Strange, I would open issue to say opposite side. I am trying to do a docker image, but If you want an image with broker and data node it little bit difficult. because broker need to announce his hostame to register, and datanode trying to register to this broker with hostname. So to fix it I need to se hostame in /etc/hosts to redirect to localhost, and give a hostname of docker machine.

This is mainly for first node starting of cluster

[easyrasta]

Strange, I would open issue to say opposite side. I am trying to do a docker image, but If you want an image with broker and data node it little bit difficult. because broker need to announce his hostame to register, and datanode trying to register to this broker with hostname. So to fix it I need to se hostame in /etc/hosts to redirect to localhost, and give a hostname of docker machine.

This is mainly for first node starting of cluster

[ckmaresca]

I am having a similar issue after changing the bind address in rc31. Changing the bind address re-binds all the daemons to the correct port, but the broker is still looking for the data node at localhost:

[[srvr] 2015/06/06 11:33:38 broker cq: no data nodes currently available.
[messaging] 2015/06/06 11:33:37 reconnecting to broker: url={http  <nil> localhost:8086 /messaging/messages index=3&streaming=true&topicID=0 }, err=Get http://localhost:8086/messaging/messages?index=3&streaming=true&topicID=0: dial tcp 127.0.0.1:8086: connection refused

I re-installed influx several times to see if I was missing something and changed the bind address before first launch, but that didn't work at all. Perhaps I'm missing something in the configs as I an incomplete understanding of influx configuration options....

I'm guessing that waiting for r32 is the thing to do, but I thought I'd log this anyway.

[ckmaresca]

I am having a similar issue after changing the bind address in rc31. Changing the bind address re-binds all the daemons to the correct port, but the broker is still looking for the data node at localhost:

[[srvr] 2015/06/06 11:33:38 broker cq: no data nodes currently available.
[messaging] 2015/06/06 11:33:37 reconnecting to broker: url={http  <nil> localhost:8086 /messaging/messages index=3&streaming=true&topicID=0 }, err=Get http://localhost:8086/messaging/messages?index=3&streaming=true&topicID=0: dial tcp 127.0.0.1:8086: connection refused

I re-installed influx several times to see if I was missing something and changed the bind address before first launch, but that didn't work at all. Perhaps I'm missing something in the configs as I an incomplete understanding of influx configuration options....

I'm guessing that waiting for r32 is the thing to do, but I thought I'd log this anyway.

[noroute]

Is there a schedule for 0.9.2? This issue is quite ugly as there is no simple workaround (or is there?)....

[noroute]

Is there a schedule for 0.9.2? This issue is quite ugly as there is no simple workaround (or is there?)....

[pauldix]

@noroute: 0.9.2 will be released on July 23rd. In the meantime, when this issue is fixed and merged into master, we have nightly builds that you can test with that can be found here: https://influxdb.com/download/index.html

[pauldix]

@noroute: 0.9.2 will be released on July 23rd. In the meantime, when this issue is fixed and merged into master, we have nightly builds that you can test with that can be found here: https://influxdb.com/download/index.html

[beckettsean]

@corylanou what's the status of this issue? Are you working on a fix like Paul seems to think?

[beckettsean]

@corylanou what's the status of this issue? Are you working on a fix like Paul seems to think?

[beckettsean]

@pauldix @toddboom it turns out @corylanou is otherwise occupied leading into the 0.9.2 code freeze. Who else do you nominate to fix this?

[beckettsean]

@pauldix @toddboom it turns out @corylanou is otherwise occupied leading into the 0.9.2 code freeze. Who else do you nominate to fix this?

[marcosnils]

@beckettsean @toddboom @pauldix I remember fixing this issue in 0.9rc some time ago. If you still agree with the solution proposed in this PR #2479 I can refloat, but please merge this time 😄

[marcosnils]

@beckettsean @toddboom @pauldix I remember fixing this issue in 0.9rc some time ago. If you still agree with the solution proposed in this PR #2479 I can refloat, but please merge this time 😄

[beckettsean]

@marcosnils thanks for the reminder! I'm not qualified to 👍 the merge but I promise to badger the appropriate people on your behalf. There was much sadness that we didn't give you a good chance to merge it last time.

[beckettsean]

@marcosnils thanks for the reminder! I'm not qualified to 👍 the merge but I promise to badger the appropriate people on your behalf. There was much sadness that we didn't give you a good chance to merge it last time.

[pauldix]

@marcosnils if you can redo it, we'd gladly merge. Sorry about not getting it in last time. I don't think there will be another big refactor that would cause a problem.

Although, looping @jwilder in to make sure his work isn't changing how server startup/binding works.

[pauldix]

@marcosnils if you can redo it, we'd gladly merge. Sorry about not getting it in last time. I don't think there will be another big refactor that would cause a problem.

Although, looping @jwilder in to make sure his work isn't changing how server startup/binding works.

[marcosnils]

@pauldix no problem, I'll submit a new PR tomorrow with the updated code. I took special care in trying not to break backwards compatibility in it, so i'd be great if you can confirm.

[marcosnils]

@pauldix no problem, I'll submit a new PR tomorrow with the updated code. I took special care in trying not to break backwards compatibility in it, so i'd be great if you can confirm.

[jwilder]

This might interfere with my changes but not sure off-hand.

Also, I'm not sure that changing the hostname would fix the original issue. I believe the original issue was that the old broker/meta-store saved the IP addresses of existing nodes and tried to reconnect to them on startup using its existing state. Changing the hostname was not supported because you would need to remove the node from the meta-store/raft and re-add it. We probably have a similar with 0.9.1 because our new raft still needs to save the raft peers and node addresses in the meta-store.

I think we'd have to detect hostname changes for a node and propagate the changes through the cluster.

[jwilder]

This might interfere with my changes but not sure off-hand.

Also, I'm not sure that changing the hostname would fix the original issue. I believe the original issue was that the old broker/meta-store saved the IP addresses of existing nodes and tried to reconnect to them on startup using its existing state. Changing the hostname was not supported because you would need to remove the node from the meta-store/raft and re-add it. We probably have a similar with 0.9.1 because our new raft still needs to save the raft peers and node addresses in the meta-store.

I think we'd have to detect hostname changes for a node and propagate the changes through the cluster.

[pauldix]

ok, based on what @jwilder said I think this is going to be more involved. Probably best to hold off for now @marcosnils.

We definitely have a thing where we need to be able to update the IP/hostname of the server. People running in Docker containers commonly have this problem.

[pauldix]

ok, based on what @jwilder said I think this is going to be more involved. Probably best to hold off for now @marcosnils.

We definitely have a thing where we need to be able to update the IP/hostname of the server. People running in Docker containers commonly have this problem.

[marcosnils]

@jwilder @pauldix I thought the main issue arose when trying to start influxdb the first time with the hostname parameter set. That is what my PR actually fixes, and what the test I've included asserts.

There's also what you're mentioning about changing the configuration parameter once the cluster has been initialized which involves change propagation.

The solution for this last situation fixes the first one, but requires thorough testing and handling complex situations. Maybe in the meantime applying my simple fix will allow users to setup a cluster using the hostname parameter.

[marcosnils]

@jwilder @pauldix I thought the main issue arose when trying to start influxdb the first time with the hostname parameter set. That is what my PR actually fixes, and what the test I've included asserts.

There's also what you're mentioning about changing the configuration parameter once the cluster has been initialized which involves change propagation.

The solution for this last situation fixes the first one, but requires thorough testing and handling complex situations. Maybe in the meantime applying my simple fix will allow users to setup a cluster using the hostname parameter.

[marcosnils]

@jwilder @pauldix you still want to go with the long shot solution?.

[marcosnils]

@jwilder @pauldix you still want to go with the long shot solution?.

[pauldix]

@marcosnils sorry for the delayed response, If your fix is just for setting the hostname initially, I think it's worth doing it. I've created #3421 to track the issue of updating the hostname/IP of a server in a cluster.

[pauldix]

@marcosnils sorry for the delayed response, If your fix is just for setting the hostname initially, I think it's worth doing it. I've created #3421 to track the issue of updating the hostname/IP of a server in a cluster.

[marcosnils]

@pauldix perfect. Shall we wait for @jwilder comments about this before I rebase?

[marcosnils]

@pauldix perfect. Shall we wait for @jwilder comments about this before I rebase?

[pauldix]

@marcosnils yeah, he still has some stuff in development that would probably make your code different. Don't want to have you go to the trouble of doing it and then clobber your stuff with an ugly rebase :)

[pauldix]

@marcosnils yeah, he still has some stuff in development that would probably make your code different. Don't want to have you go to the trouble of doing it and then clobber your stuff with an ugly rebase :)

[jwilder]

@marcosnils Sorry for the delay. If you wouldn't mind waiting for #3372 to land that would be great. Hoping to get merge that in the next day or two.

[jwilder]

@marcosnils Sorry for the delay. If you wouldn't mind waiting for #3372 to land that would be great. Hoping to get merge that in the next day or two.

[marcosnils]

@jwilder np. If you don't mind please update this when #3372 is ready so I can take a look and see if it's still necessary.

[marcosnils]

@jwilder np. If you don't mind please update this when #3372 is ready so I can take a look and see if it's still necessary.

[jwilder]

@marcosnils #3372 has landed. If you want to rebase, we should be able to merge the fix in now.

[jwilder]

@marcosnils #3372 has landed. If you want to rebase, we should be able to merge the fix in now.

[marcosnils]

@beckettsean @jwilder @pauldix this is no longer an issue. Just tried it with master branch code and works. I guess this can be closed when next release is available.

[marcosnils]

@beckettsean @jwilder @pauldix this is no longer an issue. Just tried it with master branch code and works. I guess this can be closed when next release is available.

[sagetrey]

It is still an issue. when connecting to localhost:8086 I get a connection refused. Doesn't happen when I connect to it from outside.

[sagetrey]

It is still an issue. when connecting to localhost:8086 I get a connection refused. Doesn't happen when I connect to it from outside.

[marcosnils]

@sagetrey please provide more information about which influx version you're running, the specific error you're getting (log trace) and under which address service parameter you changed. It'd be also good to know if you are configuring a new cluster or an already existing one.

[marcosnils]

@sagetrey please provide more information about which influx version you're running, the specific error you're getting (log trace) and under which address service parameter you changed. It'd be also good to know if you are configuring a new cluster or an already existing one.

[kolargol]

Reopening this as this is still issue. Influx when configured with bind-address = ":123" listen only on ipv6 interface and there is no way forcing it to use ipv4.

[kolargol]

Reopening this as this is still issue. Influx when configured with bind-address = ":123" listen only on ipv6 interface and there is no way forcing it to use ipv4.