No configuration management in place. I manually untarred the files. So all 
configuration information should be contained in the application directory? 

Here is what I see which is, even after a reboot, a Nightwatch named 
Elasticsearch instance looking for the phantom "Plantman" master, even 
though this node is configured to be a master only:

[root@es-master elasticsearch-1.4.2]# 
[2015-01-16 11:57:43,500][INFO ][node                     ] [*Nightwatch*] 
version[1.4.2], pid[24139], build[927caff/2014-12-16T14:11:12Z]
[2015-01-16 11:57:43,501][INFO ][node                     ] [Nightwatch] 
initializing ...
[2015-01-16 11:57:43,505][INFO ][plugins                  ] [Nightwatch] 
loaded [], sites []
[2015-01-16 11:57:46,701][INFO ][node                     ] [Nightwatch] 
initialized
[2015-01-16 11:57:46,701][INFO ][node                     ] [Nightwatch] 
starting ...
[2015-01-16 11:57:46,903][INFO ][transport                ] [Nightwatch] 
bound_address {inet[/0:0:0:0:0:0:0:0:9300]}, publish_address 
{inet[/10.0.0.45:9300]}
[2015-01-16 11:57:46,919][INFO ][discovery                ] [Nightwatch] 
lsflogs/A6CISFuzRkK31rL2dFFdNA
[2015-01-16 11:57:50,187][INFO ][discovery.zen            ] [Nightwatch] 
*failed 
to send join request to master 
[[Plantman]*[VOmbX4yORHiObk7Q3D7tbQ][es-master][inet[/10.0.0.45:9300]]{data=false,
 
master=true}], reason 
[RemoteTransportException[[Nightwatch][inet[/10.0.0.45:9300]][internal:discovery/zen/join]];
 
nested: ElasticsearchIllegalStateException[Node 
[[Nightwatch][A6CISFuzRkK31rL2dFFdNA][es-master][inet[/10.0.0.45:9300]]{data=false,
 
master=true}] not master for join request from 
[[Nightwatch][A6CISFuzRkK31rL2dFFdNA][es-master][inet[/10.0.0.45:9300]]{data=false,
 
master=true}]]; ], tried [3] times

My workaround was to rename the cluster. Perhaps there was another node 
with that information and it was confusing the master? 

But you answered my question which is there is no information written 
outside of the application directory that could cache settings for future 
clusters if I tear them down and rebuild them.

Thanks
Albion


On Wednesday, January 14, 2015 at 6:42:23 PM UTC-8, Mark Walkom wrote:
>
> It doesn't cache this sort of info, it'll read what is in the config file.
>
> Are you using puppet/chef/other for config management perchance? These 
> could be over writing your config.
>
> On 15 January 2015 at 06:22, Albion Baucom <[email protected] <javascript:>> 
> wrote:
>
>> I am new to ELK and I am still using a dev environment with real data to 
>> understand how the pipeline works.
>>
>> Recently I had nodes networking between them that were part of a 4 node 
>> cluster: 1 master node, no data and 3 data-only nodes. These were working 
>> fine up to the point that they lost connectivity between themselves. I am 
>> using a unicast cluster setup as multicast was not working on my OpenStack 
>> cluster (a question for another future post).
>>
>> When I rebooted the nodes and tried to bring the master back up it tried 
>> to join the previous master instance. Clearly there is information cached 
>> about the previous running instance that needs to be flushed. As this is a 
>> dev environment, I copied the config file and blew away the elastic search 
>> directory, copied the config back and tried to restart elasticsearch. 
>> Curiously it is still trying to join the old master, even though no other 
>> processes are running. Obviously this cached data lives somewhere else on 
>> the system and I have yet to find it.
>>
>> Perhaps someone can point me in the right direction here.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "elasticsearch" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elasticsearch/90187018-dde9-447d-b211-d806fd46cec8%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/elasticsearch/90187018-dde9-447d-b211-d806fd46cec8%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/12876abb-4c7c-4ef8-934f-d0afac8b8c3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to