El Lunes, 28 de Diciembre de 2009, Eric Wong escribió:
> > It's really awesome! I've tested it and it works great, and avoids the
> > sleeping stuff and a new commandlline option. Congratulations :)
>
> The current version is actually slightly buggy in that it leaks
> the pipe descriptor...
I've detected some other "issue":
Imagine port 80 is used by other application (as apache) and Unicorn is
configured to also bind in same port.
When running it in foreground all is great:
ERROR -- : adding listener failed addr=0.0.0.0:80 (in use)
ERROR -- : retrying in 3 seconds (1 tries left)
ERROR -- : adding listener failed addr=0.0.0.0:80 (in use)
ERROR -- : retrying in 3 seconds (0 tries left)
ERROR -- : adding listener failed addr=0.0.0.0:80 (in use)
/usr/local/lib/ruby1.9/site_ruby/1.9.1/unicorn/socket_helper.rb:110:in
`initialize': Address already in use - bind(2) (Errno::EADDRINUSE)
But when running in background an ugly error is displayed:
/usr/local/lib/ruby1.9/site_ruby/1.9.1/unicorn/launcher.rb:45:in `sysread':
end of file reached (EOFError)
from /usr/local/lib/ruby1.9/site_ruby/1.9.1/unicorn/launcher.rb:45:in
`daemonize!'
In both cases $? is 1 (error) but in the last case the error message is not
very useful.
I suspect what is happening: the master tries several times to bind and after
N retries it terminates (so it closes the pipe and grandparent gets EOFError).
As a suggestion, could the grandparent rescue such exception and display some
kind of error message?:
"The master couldn't be started. Inspect the log error or run in foreground"
Regards.
--
Iñaki Baz Castillo <[email protected]>
_______________________________________________
Unicorn mailing list - [email protected]
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying