Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setup step hangs while installing on Ubuntu 14.04 #11

Closed
barryw opened this issue Feb 15, 2017 · 7 comments
Closed

Setup step hangs while installing on Ubuntu 14.04 #11

barryw opened this issue Feb 15, 2017 · 7 comments

Comments

@barryw
Copy link

barryw commented Feb 15, 2017

I'm trying to install on Ubuntu 14.04 with Couchbase as the backing store.

It says it finishes successfully, but never returns to the prompt. I see this:

root@ip-10-242-20-17:/opt/cronicle# /opt/cronicle/bin/control.sh setup
[ERROR] Failed to fetch key: global/users: The key does not exist on the server
[ERROR] Failed to fetch key: global/users: The key does not exist on the server
[ERROR] Failed to fetch key: global/plugins: The key does not exist on the server
[ERROR] Failed to fetch key: global/categories: The key does not exist on the server
[ERROR] Failed to fetch key: global/server_groups: The key does not exist on the server
[ERROR] Failed to fetch key: global/servers: The key does not exist on the server
[ERROR] Failed to fetch key: global/schedule: The key does not exist on the server
[ERROR] Failed to fetch key: global/api_keys: The key does not exist on the server
Setup completed successfully!
This server (ip-10-242-20-17) has been added as the single primary master server.
An administrator account has been created with username 'admin' and password 'admin'.
You should now be able to start the service by typing: '/opt/cronicle/bin/control.sh start'
Then, the web interface should be available at: http://ip-10-242-20-17:3012/
Please allow for up to 60 seconds for the server to become master.

And it just sits there.

Any ideas?

I'm using Node 7.5.0

@jhuckaby
Copy link
Owner

Hey @barryw,

Sorry about this. Looks like something is definitely wrong with Cronicle's connection to your Couchbase server, because those errors should not be happening. It should have failed right then and there, at the very first error. I suspect the setup script is also doing terrible error checking, and it is reporting success when it, in fact, failed.

If you could, please run these three commands on your Cronicle server and copy & paste all the output here:

cd /opt/cronicle
./bin/storage-cli.js list_create test1 --debug
./bin/storage-cli.js list_info test1 --debug
./bin/storage-cli.js list_delete test1 --debug

That should help us track down what is going on.

Thanks.

@barryw
Copy link
Author

barryw commented Feb 15, 2017

Thanks for jumping on this. It's been driving me crazy! The weird thing is that it actually creates items in the Couchbase bucket! I just assumed that it worked.

Anyway, I tried to run the commands above and it hangs on list_create

root@ip-10-242-11-99:/opt/cronicle# ./bin/storage-cli.js list_create test1 --debug
[DEBUG] Setting up storage system
[DEBUG] Setting up Couchbase
[DEBUG] Creating new list: test1 ({"page_size":50,"first_page":0,"last_page":0,"length":0,"type":"list"})
[DEBUG] Fetching Couchbase Object: test1
[ERROR] Failed to fetch key: test1: The key does not exist on the server
[DEBUG] Storing Couchbase JSON Object: test1
[DEBUG] Store complete: test1
[DEBUG] Storing Couchbase JSON Object: test1/0
[DEBUG] Store complete: test1/0
List created successfully: test1

Actually, it hangs on each command. If I run the list_info after hitting CTRL-C I see this:

root@ip-10-242-11-99:/opt/cronicle# ./bin/storage-cli.js list_info test1 --debug
[DEBUG] Setting up storage system
[DEBUG] Setting up Couchbase
[DEBUG] Loading list: test1
[DEBUG] Fetching Couchbase Object: test1
[DEBUG] JSON fetch complete: test1
List Header: test1: {
	"page_size": 50,
	"first_page": 0,
	"last_page": 0,
	"length": 0,
	"type": "list"
}

[DEBUG] Loading list page: test1/0
[DEBUG] Fetching Couchbase Object: test1/0
[DEBUG] JSON fetch complete: test1/0
Page 0: 0 items

followed by

root@ip-10-242-11-99:/opt/cronicle# ./bin/storage-cli.js list_delete test1 --debug
[DEBUG] Setting up storage system
[DEBUG] Setting up Couchbase
[DEBUG] Deleting list: test1
[DEBUG] Locking key: |test1
[DEBUG] Loading list: test1
[DEBUG] Fetching Couchbase Object: test1
[DEBUG] JSON fetch complete: test1
[DEBUG] Storing Couchbase JSON Object: test1
[DEBUG] Store complete: test1
[DEBUG] Storing Couchbase JSON Object: test1/0
[DEBUG] Store complete: test1/0
[DEBUG] Unlocking key: |test1
List deleted successfully: test1

@jhuckaby
Copy link
Owner

Oh wow, that's really strange. Okay, let me spin up an Ubuntu box on AWS and try to get things into the same state yours is in. I'll get right back to you on this.

@barryw
Copy link
Author

barryw commented Feb 15, 2017

If it helps, I'm using Couchbase 4.6 (which hasn't been released yet!). We also have 4.5.1 that I could try

@jhuckaby
Copy link
Owner

Okay, everything should be fixed now, in Cronicle v0.6.7: https://github.com/jhuckaby/Cronicle/releases/tag/v0.6.7

Note that those [ERROR] lines are actually benign, and are just caused by the command-line script being too verbose (this will be fixed in a future release). As you suspected, the Couchbase calls are actually working fine. The problem was that the setup script was not properly shutting down the Couchbase connection, and Node.js was holding open the script and not allowing it to exit.

I tested everything on Ubuntu 14 with Couchbase 4.5 and Node 7.5, and it all seems to be happy. However, I have to warn you about something. I just happened to notice this from your original issue report:

Then, the web interface should be available at: http://ip-10-242-20-17:3012/
Please allow for up to 60 seconds for the server to become master.

That IP address looks rather... cloudy. Is your server in AWS by any chance? Or Google Compute or Azure for that matter. My reason for asking is, the Cronicle UI will attempt to open a WebSocket connection from your browser to the server using its LAN IP (in your case 10.242.20.17). You'll need to have a network route from your PC/Mac to this IP, i.e. you need to be on a VPN if using AWS or equivalent cloudy system with a Virtual Private Cloud.

I may try to fix this in a future version of Cronicle, i.e. try to detect if the server has a "public" IP and use that for the WebSocket. But for now, it has to connect over the LAN IP of the server.

Thanks for the bug report!

@barryw
Copy link
Author

barryw commented Feb 16, 2017

Awesome. I really appreciate this.

We are running on AWS and I tried with private IP at first (with ssh tunnel to VPC) and then public IP with wide-open security group, but neither worked.

I will set this up using an ALB (it supports web sockets out of the box) fronting a 3 node Cronicle cluster, so I think we'll be ok.

Thanks again for your help!
-Barry

@jhuckaby
Copy link
Owner

No problem, man! Oh, one last thing. If you still have trouble getting the UI to connect to your cloud server with that private IP, might want to try this option:

https://github.com/jhuckaby/Cronicle#web_socket_use_hostnames

Note that you'll have to set your server's hostname to something that resolves to a public IP in DNS, but then the UI will connect its WebSocket to that, rather than the LAN IP of the server. This usually gets around the problem for most people.

Good luck!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants