Re: Unicorn Nginx Issue

[Matt Mongeau <halogenandtoast@gmail.com>]

On Tue, Oct 13, 2009 at 3:43 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Matt Mongeau <halogenandtoast@gmail.com> 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
> mongrel-unicorn@rubyforge.org
> 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