Exhibitor is deleting the myid files and then not able to start zookeeper due to it

[piyush tiwari]

 
Hi,

I am putting this issue which has already been seen in the group because there is no concrete solution for this issue (ISSUE). I am facing the similar issue where I am setting up a 2 node zookeeper cluster with exhibitor installed on the same, Whenever I change the configuration from the exhibitor GUI which causes zookeeper instances to restart, exhibitor go and stop zookeeper instances and delete myid files and then not able to start zookeeper.

It would be great If someone provide a concrete solution to this problem as it is a show stopper.

Thanks & Regards,
Piyush Tiwari

[Jordan Zimmerman]

That’s a feature of Exhibitor. It manages zoo.cfg and the mid file for you. Turn off instance restarts to disable this feature.

-Jordan

--
You received this message because you are subscribed to the Google Groups "exhibitor-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exhibitor-use...@googlegroups.com.
To post to this group, send email to exhibit...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/exhibitor-users/257e7284-ff8d-46d2-a6c9-e2d663eaf10f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Pechner]

That did not work.

Turned off restarts.

Then tried turning off Automatic Server List Add/Remove for the hell of it.

Exhibitor still insists on removing myid

[David McClain]

Was there ever a fix for this? I just compiled what I found to be the most recent version (1.5.6) and encountered this same issue. 
It's not a 'feature' if it breaks the app.

If we want Exhibitor to restart Zookeeper, then it needs to be able to restart it.

Currently it seems to be deleting myid, not creating it with the appropriate values, and thus is unable to restart zookeeper - leaving zookeeper NOT running after any restart attempt.

[Parker Gordon]

Also running into this. Will post a fix once i've come across it. I believe it has to do with the confusion of wether zookeeper should be started prior to exhibitor, or could be a config issue.

[Parker Gordon]

So, I was able to fix this issue by ensuring a few things:

1. I use chef for deployment so I made sure zookeeper was never started by chef, only managed by Exhibitor

2. I create a zoo.cfg with chef, but I DO NOT add server listings to the file. This will murk with consistency. (This probably shouldn't be done at all)

3. When you run Exhibitor, run it as root, or make sure all directories related to zookeeper are given open permissions to the profile running exhibitor

       - In my case I run it as root, meh, but

Doing these things solved it for me! Number 3 was crucial

[Parker Gordon]

I almost forgot!

Set this param option when running exhibitor! This was crucial!!

--hostname <IP of box> 

E.g. "nohup java -jar /opt/app1/zookeeper/exhibitor.jar --hostname 172.18.4.249 --defaultconfig /opt/app1/zookeeper/conf/exhibitor.properties --configtype file > /opt/app1/zookeeper/exhibitorNohup.log 2> /opt/search/zookeeper/exhibitorNohup.error.log &"

[ch...@scalyr.com]

For me, the critical part was ensuring that whatever's specified in the --hostname param is identical to whatever's in the ZK ensemble config.

So if you have "--hostname zk1.mycompany.com" on the exhibitor command line, your ZK ensemble config should be "S:1:zk1.mycompany.com,S:2:zk2.mycompany.com:3:zk3.mycompany.com"

If you don't explicitly specify a --hostname param, exhibitor will just use the short hostname, so if your ZK ensemble config specifies FQDNs, there will be a mismatch. Exhibitor won't write the myid file, and therefore it won't be able to successfully start ZK.

I didn't want to explicitly specify a --hostname param, so I just used short hostnames in my ZK ensemble config (e.g. "S:1:zk1,S:2:zk2:3:zk3" and everything worked just file.