# Unicorn 0.97.0 - polishing and cleaning up

**URL:** <https://www.ruby-forum.com/t/unicorn-0-97-0-polishing-and-cleaning-up/184380>\
**Category:** Ruby\
**Created:** [March 1, 2010, 7:43pm UTC](https://www.ruby-forum.com/t/unicorn-0-97-0-polishing-and-cleaning-up/184380 "2010-03-01T19:43:26Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![ericw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/97f17d/32.png) [@ericw](https://www.ruby-forum.com/u/ericw)\
**Post date:** [March 1, 2010, 7:43pm UTC](https://www.ruby-forum.com/t/unicorn-0-97-0-polishing-and-cleaning-up/184380/1 "2010-03-01T19:43:26Z")

</div>

Unicorn is an HTTP server for Rack applications designed to only serve  
fast clients on low-latency, high-bandwidth connections and take  
advantage of features in Unix/Unix-like kernels. Slow clients should  
only be served by placing a reverse proxy capable of fully buffering  
both the the request and response in between Unicorn and slow clients.

- [http://unicorn.bogomips.org/](http://unicorn.bogomips.org/)
- removed\_email\_address@domain.invalid
- git://git.bogomips.org/unicorn.git

Changes:

A bunch of small fixes related to startup/configuration and hot  
reload issues with HUP:

- Variables in the user-generated [config.ru](http://config.ru) files no longer  
risk clobbering variables used in laucher scripts.

- signal handlers are initialized before the pid file is  
dropped, so over-eager firing of init scripts won’t  
mysteriously nuke a process.

- SIGHUP will return app to original state if an updated  
[config.ru](http://config.ru) fails to load due to {Syntax,Load}Error.

- unicorn\_rails should be Rails 3 compatible out-of-the-box  
(‘unicorn’ works as always, and is recommended for Rails 3)

- unicorn\_rails is finally “working\_directory”-aware when  
generating default temporary paths and pid file

- [config.ru](http://config.ru) encoding is the application’s default in 1.9,  
not forced to binary like many parts of Unicorn.

- configurator learned to handle the “user” directive outside  
of after\_fork hook (which will always remain supported).

There are also various internal cleanups and possible speedups.