bobthecow/genghis

Browser gets no response. App fails to load after 1st attempt

Opened this issue · 17 comments

I'm running macosx 10.9.5 and ruby 2.0.0p481 (2014-05-08 revision 45883) [universal.x86_64-darwin13]. Genghis was running well for me in the past. I'm not sure what changed, but now it does not run.

When my machine first boots and I launch genghis, it will start the browser and point it at 0.0.0.0:5678. The browser will just spin, though.

If I try to kill genghis and restart it, it stalls and eventually times out with There was an error starting 'genghisapp': Net::ReadTimeout

I navigated to ~/.vegas/genghisapp/genghisapp.log. There are no new log events added to the log file and the last log data was from the last successful program execution. The last few lines in that file are:

log writing failed. can't be called from trap context
log writing failed. can't be called from trap context
[2014-10-30 15:40:19] INFO  going to shutdown ...
[2014-10-30 15:40:19] INFO  WEBrick::HTTPServer#start done.

Please let me know if I can provide any more information to help track this down. I love genghis and hope that this can be resolved. Thanks!

If you reload the browser after it tries to load that first time, does it work?

What happens if you run it as genghisapp --foreground?

Still no luck... I originally ran it with the parameter that you mentioned and then I ran it with genghisapp -x -d --foreground

The output was:

[2014-11-05 14:24:55 -0600] Starting 'genghisapp'...
[2014-11-05 14:24:55 -0600] trying port 5678...
[2014-11-05 14:24:55 -0600] Running with Rack handler: Rack::Handler::WEBrick
[2014-11-05 14:24:55] INFO  WEBrick 1.3.1
[2014-11-05 14:24:55] INFO  ruby 2.0.0 (2014-05-08) [universal.x86_64-darwin13]
[2014-11-05 14:24:55] INFO  WEBrick::HTTPServer#start: pid=401 port=5678

Meanwhile, the browser does not respond to requests to 0.0.0.0:5678. When I try to terminate the genghis process with ctrl-c, I get the following:

^Clog writing failed. can't be called from trap context
[2014-11-05 14:28:33] INFO  going to shutdown ...

It doesn't shut down at that point and just hangs...

Is ruby 2.0.0p481 your system ruby?

Yes, but I'm not tied to that - I am happy to change versions, if needed.

I don't have a preference, I was just trying to rule out weirdness due to multiple Rubies :)

Any other ideas or things you'd like me to try?

Hi,

Same bug for me, everything is the same.

Config :
Mac OS X 10.9.5.
ruby 2.0.0p481 (2014-05-08 revision 45883) [universal.x86_64-darwin13].
All gems up to date.

Too bad, genghis is so useful ! :-(

I've been completely unable to reproduce this. Do (both of) you mind trying the development branch and seeing if it happens there?

git clone https://github.com/bobthecow/genghis.git
cd genghis
git checkout develop
gem build genghisapp.gemspec
gem install genghisapp-3.0.0.dev.gem

That version works for me. Thanks!

Sadly, it is the same for me when I launch genghisapp after installing dev gem. No response.

Okay. Do you mind running gem query --local and pasting the results in here?

If it matters, this is the output on my machine:

backports (3.6.3)
bigdecimal (1.2.0)
bson (1.11.1, 1.9.2)
bson_ext (1.11.1)
CFPropertyList (2.2.0)
genghis (1.4.1)
genghisapp (3.0.0.dev)
io-console (0.4.2)
json (1.7.7)
libxml-ruby (2.6.0)
minitest (4.3.2)
mongo (1.11.1, 1.9.2)
multi_json (1.10.1)
mustache (0.99.7)
nokogiri (1.5.6)
psych (2.0.0)
rack (1.5.2)
rack-protection (1.5.3)
rack-test (0.6.2)
rake (0.9.6)
rdoc (4.0.0)
rubygems-update (2.4.2)
sass (3.4.7)
sinatra (1.4.5)
sinatra-contrib (1.4.2)
sinatra-mustache (0.3.2)
sqlite3 (1.3.7)
test-unit (2.0.0.0)
tilt (1.4.1)
vegas (0.1.11)

Sure !

Here you are :

backports (3.6.4, 3.6.3, 3.6.0)
bigdecimal (1.2.5, 1.2.0)
bson (2.3.0, 1.11.1, 1.9.2)
bson_ext (1.11.1, 1.9.2)
CFPropertyList (2.2.8, 2.2.7, 2.2.0)
genghisapp (3.0.0.dev, 2.3.11)
io-console (0.4.2)
json (1.8.1, 1.7.7)
libxml-ruby (2.7.0, 2.6.0)
mini_portile (0.6.1, 0.6.0, 0.5.2)
minitest (5.4.3, 5.4.2, 5.3.4, 4.3.2)
mongo (1.11.1, 1.9.2)
multi_json (1.10.1, 1.9.2)
mustache (0.99.7, 0.99.6, 0.99.5)
nokogiri (1.6.4.1, 1.6.3.1, 1.6.2.1, 1.5.6)
power_assert (0.2.0, 0.1.4)
psych (2.0.6, 2.0.5, 2.0.0)
rack (1.5.2)
rack-protection (1.5.3)
rack-test (0.6.2)
rake (10.3.2, 0.9.6)
rdoc (4.1.2, 4.1.1, 4.0.0)
rubygems-update (2.4.3, 2.4.2, 2.2.2)
sinatra (1.4.5)
sinatra-contrib (1.4.2)
sinatra-mustache (0.3.2, 0.3.1)
sqlite3 (1.3.10, 1.3.9, 1.3.7)
test-unit (3.0.6, 3.0.2, 3.0.1, 2.5.5, 2.0.0.0)
tilt (2.0.1, 1.4.1)
vegas (0.1.11)

Hi,

It has been a while, and I decided today to cleanup my environment and start afresh.

I deleted all gems of genghisapp, and saw its dependencies were not uninstalled. So I removed also mongo, bson, bson_ext and reinstalled genghisapp. And it worked ! :-)

Thanks for your work, and happy to hear a v3 is in the closet.

Benoit

@bobthecow I seem to be experiencing this same issue exactly as jgeurts described: Genghis has been working fine for me since installing a week or two ago. I booted up today and the browser just spins once it opens the tab. Refreshing that tab doesn't make a difference. I uninstalled and installed the 3.0 dev version as described above and the tab at least loads, but there is a constant loading icon as it tries to load the list of dbs. Opening the Chrome network tab, the request to /servers seems to fail with the response {"error":"uninitialized constant Mongo::MongoArgumentError","status":500}. Any other thoughts on how to resolve this? Here is my list of local gems:

*** LOCAL GEMS ***

backports (3.6.4)
bigdecimal (1.2.7, 1.2.0)
bson (3.0.3, 1.12.2, 1.9.2)
bson_ext (1.12.2, 1.9.2)
CFPropertyList (2.3.1, 2.2.8)
genghisapp (3.0.0.dev)
io-console (0.4.2)
json (1.8.2, 1.7.7)
libxml-ruby (2.8.0, 2.6.0)
mini_portile (0.6.2)
minitest (5.6.1, 4.3.2)
mongo (2.0.4, 1.9.2)
multi_json (1.11.0)
mustache (1.0.1, 0.99.8)
nokogiri (1.6.6.2, 1.5.6)
power_assert (0.2.3)
psych (2.0.13, 2.0.0)
rack (1.6.1)
rack-protection (1.5.3)
rack-test (0.6.3)
rake (0.9.6)
rdoc (4.0.0)
rubygems-update (2.4.7)
sass (3.4.14, 3.4.13)
sinatra (1.4.6)
sinatra-contrib (1.4.2)
sinatra-mustache (0.3.2)
sqlite3 (1.3.10, 1.3.7)
test-unit (3.0.9, 2.0.0.0)
tilt (1.4.1)
vegas (0.1.11)

Also, here are the log entries related to this:

[2015-06-01 10:46:48 -0500] Running with Rack handler: Rack::Handler::WEBrick
[2015-06-01 10:46:48] INFO  WEBrick 1.3.1
[2015-06-01 10:46:48] INFO  ruby 2.0.0 (2014-05-08) [universal.x86_64-darwin14]
[2015-06-01 10:46:48] INFO  WEBrick::HTTPServer#start: pid=2849 port=5678
localhost - - [01/Jun/2015:10:46:49 CDT] "GET / HTTP/1.1" 200 2943
- -> /
localhost - - [01/Jun/2015:10:46:49 CDT] "GET /js/script.js?v=3.0.0-dev HTTP/1.1" 200 532046
http://0.0.0.0:5678/ -> /js/script.js?v=3.0.0-dev
localhost - - [01/Jun/2015:10:46:49 CDT] "GET /css/style.css?v=3.0.0-dev HTTP/1.1" 200 138504
http://0.0.0.0:5678/ -> /css/style.css?v=3.0.0-dev
2015-06-01 10:46:49 - NameError - uninitialized constant Mongo::MongoArgumentError:
    /Library/Ruby/Gems/2.0.0/gems/genghisapp-3.0.0.dev/genghis.rb:624:in `rescue in initialize'
    /Library/Ruby/Gems/2.0.0/gems/genghisapp-3.0.0.dev/genghis.rb:604:in `initialize'
    /Library/Ruby/Gems/2.0.0/gems/genghisapp-3.0.0.dev/genghis.rb:896:in `new'
    /Library/Ruby/Gems/2.0.0/gems/genghisapp-3.0.0.dev/genghis.rb:896:in `block in init_servers'
    /Library/Ruby/Gems/2.0.0/gems/genghisapp-3.0.0.dev/genghis.rb:895:in `map'
    /Library/Ruby/Gems/2.0.0/gems/genghisapp-3.0.0.dev/genghis.rb:895:in `init_servers'
    /Library/Ruby/Gems/2.0.0/gems/genghisapp-3.0.0.dev/genghis.rb:886:in `servers'
    /Library/Ruby/Gems/2.0.0/gems/genghisapp-3.0.0.dev/genghis.rb:1052:in `block in <class:Server>'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1610:in `call'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1610:in `block in compile!'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:974:in `[]'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:974:in `block (3 levels) in route!'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:993:in `route_eval'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:974:in `block (2 levels) in route!'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1014:in `block in process_route'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1012:in `catch'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1012:in `process_route'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:972:in `block in route!'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:971:in `each'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:971:in `route!'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1084:in `block in dispatch!'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `block in invoke'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `catch'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `invoke'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1081:in `dispatch!'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:906:in `block in call!'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `block in invoke'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `catch'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `invoke'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:906:in `call!'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:894:in `call'
    /Library/Ruby/Gems/2.0.0/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18:in `call'
    /Library/Ruby/Gems/2.0.0/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18:in `call'
    /Library/Ruby/Gems/2.0.0/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in `call'
    /Library/Ruby/Gems/2.0.0/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in `call'
    /Library/Ruby/Gems/2.0.0/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31:in `call'
    /Library/Ruby/Gems/2.0.0/gems/rack-1.6.1/lib/rack/nulllogger.rb:9:in `call'
    /Library/Ruby/Gems/2.0.0/gems/rack-1.6.1/lib/rack/head.rb:13:in `call'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:181:in `call'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:2021:in `call'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1486:in `block in call'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1795:in `synchronize'
    /Library/Ruby/Gems/2.0.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1486:in `call'
    /Library/Ruby/Gems/2.0.0/gems/rack-1.6.1/lib/rack/handler/webrick.rb:89:in `service'
    /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/webrick/httpserver.rb:138:in `service'
    /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/webrick/httpserver.rb:94:in `run'
    /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/webrick/server.rb:295:in `block in start_thread'
localhost - - [01/Jun/2015:10:46:49 CDT] "GET /servers HTTP/1.1" 500 73
http://0.0.0.0:5678/ -> /servers
localhost - - [01/Jun/2015:10:46:49 CDT] "GET /check-status HTTP/1.1" 200 177
http://0.0.0.0:5678/ -> /check-status
log writing failed. can't be called from trap context

I found that the solution from @DiesIrae worked for me too. I think the problem was either multiple versions of mongo or a version that was too new. I had both 2.0.4 and 1.9.2 installed. The first was likely from my initial install of mongo via homebrew that likely installed the latest. 1.9.2 was likely added as part of genghis. So I uninstalled mongo, bson, bson_ext, and genghis, and then I did gem install genghisapp which installed all the dependent versions. The app came up right away.

So the issue might be related to having the newest version of mongo installed.

On a side note for anyone else who sees this and does the uninstall, all of my data stayed in place through the uninstall/reinstall, so I didn't need to restore the dump I took beforehand.