On Tue, Oct 13, 2009 at 3:43 PM, Eric Wong <[email protected]> wrote: > Matt Mongeau <[email protected]> wrote: >> sudo gem check -t unicorn > > Again, please don't top post on this mailing list (nor on other technical > mailing lists in general). > >> fails >> >> Failure: >> test_rack_lint_big_put(RequestTest) [./test/unit/test_request.rb:178]: >> <nil> expected but was >> <" >> >> followed by lots whitespace >> >> ">. > > Unrelated to the problem we were having, but this really should be > working, especially with 0.93.2 or later. Is anybody else out there > hitting this? > >> Error: >> test_expand_addr(TestConfigurator): >> SocketError: getaddrinfo: nodename nor servname provided, or not known >> >> /opt/local/lib/ruby/gems/1.8/gems/unicorn-0.93.2/lib/unicorn/configurator.rb:346:in >> `pack_sockaddr_in' >> >> /opt/local/lib/ruby/gems/1.8/gems/unicorn-0.93.2/lib/unicorn/configurator.rb:346:in >> `expand_addr' >> ./test/unit/test_configurator.rb:35:in `call' >> ./test/unit/test_configurator.rb:35:in `test_expand_addr' > > This looks like a portability issue. I'll probably rip those tests out > since a good chunk of systems don't addresses like this. > > But above this test failure, the other test_expand_addr assertions > manage to pass which is strange, namely the following: > > meth = Unicorn::Configurator.new.method(:expand_addr) > > assert_equal "/var/run/unicorn.sock", meth.call("/var/run/unicorn.sock") > assert_equal "#{Dir.pwd}/foo/bar.sock", meth.call("unix:foo/bar.sock") > > Your original paths were under 104 bytes, too[1] > >> >> I had >> >> listen >> >> '/Users/mattmongeau/projects/test/unicorn/tmp/sockets/unicorn.sock', >> >> :backlog => 1024 >> >> I guess I needed >> >> listen >> >> 'unix:/Users/mattmongeau/projects/test/unicorn/tmp/sockets/unicorn.sock', >> >> :backlog => 1024 > > Does using a shorter path help at all? > > Shorter (and shallower) paths are even a small bit faster because the > filesystem has to do less work to resolve it for every connection :) > > [1] - http://portabilityblog.com/blog/archives/4-UNIX-domain-sockets.html > > -- > Eric Wong > _______________________________________________ > mongrel-unicorn mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/mongrel-unicorn > Sorry for top posting, I actually didn't know what you meant by that... had to have someone else explain it to me.
Ok my previous problem seems to be from running unicorn_rails multiple times so if I run unicorn_rails -c config/unicorn.rb -E development -D it works fine (with and without the unix prefix on the socket) then if I just run unicorn_rails -c config/unicorn.rb -E development without killing the current master everything seems to work if I issue a term signal ^C to it and try unicorn_rails -c config/unicorn.rb -E development -D it no longer works seems like I shouldn't issue these commands in tandem without first killing the previous unicorn instance _______________________________________________ mongrel-unicorn mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn
