about summary refs log tree commit homepage
path: root/lib/unicorn/launcher.rb
DateCommit message (Collapse)
2011-04-18documentation cleanup/reduction
Don't clutter up our RDoc/website with things that users of Unicorn don't need to see. This should make user-relevant documentation easier to find, especially since Unicorn is NOT intended to be an API.
2010-08-30remove nasty ugly hacks at startup
These nasty hacks were breaking Rubinius compatibility. This can be further cleaned up, too.
2010-07-13launcher: do not re-daemonize when USR2 upgrading
This was accidentally enabled when ready_pipe was developed. While re-daemonizing appears harmless in most cases this makes detecting backed-out upgrades from the original master process impossible.
2010-06-11cleanup: use modules were applicable
No point in having namespaces be classes when we never create instances of them...
2010-06-10respect "working_directory" wrt config.ru
Since we added support for the "working_directory" parameter, it often became unclear where/when certain paths would be bound. There are some extremely nasty dependencies and ordering issues when doing this. It's all pretty fragile, but works for now and we even have a full integration test to keep it working. I plan on cleaning this up 2.x.x to be less offensive to look at (Rainbows! and Zbatery are a bit tied to this at the moment). Thanks to Pierre Baillet for reporting this. ref: http://mid.gmane.org/AANLkTimKb7JARr_69nfVrJLvMZH3Gvs1o_KwZFLKfuxy@mail.gmail.com
2010-06-10launcher: get rid of backwards compatibility code
Rainbows! and Zbatery have long been upgraded to pass options to us.
2009-12-29launcher: no point in sync-ing $stdin
Inspection of the MRI source reveals that IO#sync=true only appears to only apply for writes. Though it could eventually make sense to disable read buffering by setting IO#sync=true, it does not appear to happen. Of course we never read from $stdin anyways....
2009-12-29launcher: fix compatibility with other servers
Rainbows! does not yet know about ready_pipe, and will probably not know about it until Unicorn 0.97.0
2009-12-28launcher: descriptive error message on startup failure
Rather than erroring out with a non-descript EOFError, show a warning message telling users to check the logs instead. Reported-by: Iñaki Baz Castillo mid=200912281350.44760.ibc@aliax.net
2009-12-27Avoid leaking ready pipe file descriptor to workers
Otherwise the original spawner process may not notice the close as it's still being shared by workers. While we're at it, avoid confusing the original spawner by using readpartial instead of sysread.
2009-12-26exit with failure if master dies when daemonized
This behavior change also means our grandparent (launched from a controlling terminal or script) will wait until the master process is ready before returning. Thanks to Iñaki Baz Castillo for the initial implementations and inspiration.
2009-09-08"encoding: binary" comments for all sources (1.9)
This ensures any string literals that pop up in *our* code will just be a bag of bytes. This shouldn't affect/fix/break existing apps in most cases, but most constants will always have the "correct" encoding (none!) to be consistent with HTTP/socket expectations. Since this comment affects things only on a per-source basis, it won't affect existing apps with the exception of strings we pass to the Rack application. This will eventually allow us to get rid of that Unicorn::Z constant, too.
2009-09-02launcher: defer daemonized redirects until config is read
Otherwise errors in the Unicorn-specific config files can get error messages swallowed up when daemonizing.
2009-03-19start libifying common launcher code
The daemonization logic between unicorn and unicorn_rails scripts can definitely be shared. Again: our daemonization logic is slightly non-standard since our executables are designed to run in APP_ROOT/RAILS_ROOT and not "/" like "normal" UNIX daemons.