Fwd: Support for Soft Timeout in Unicorn
normalperson at yhbt.net
Thu Jun 3 14:22:46 EDT 2010
Pierre Baillet wrote:
> We use Unicorn at fotopedia since yesterday in production. We switched from
> Passenger due to an issue in the way Passenger was handling some error in
> our main application. Things run very well on Unicorn.
> We have also modified Unicorn to handle a soft timeout for its workers. The
> Unicorn timeout was killing the workers without any chance for us to catch
> the Rails stack trace and identify the issue. I've forked and branched
> Unicorn from github and added a soft_timeout configuration value that is
> used for long running workers.
> The workers now handle SIGABRT and will raise an exception. This will crash
> the Rails application if it can be crashed and force the framework to dump
> the stack trace in the logs. Let me know if this might be useful for other
> people and, why not, integrate that in the main Unicorn code !
I'm thinking there's a better way to do this without involving the
The current timeout implementation is really the last resort,
point-of-no-return situations when the workers are completely
stuck/blocked and cannot respond to other signals. If the worker can
respond to SIGABRT (especially going through the interpreter and raising
an exception), then that means it could technically respond to
Unfortunately, the current core Ruby timeout implementation is extremely
naive and inefficient. It shouldn't be hard to write a better timeout
implementation that reuses a single timer Thread which can be rearmed
with every request.
This would be doable as middleware, too, and if done carefully, even
safely reusable in multi-threaded web servers. This would be a good
addition to rack-contrib, even. I might consider doing it myself if I
 - I'm not completely happy with "needing" the current timeout
implementation in the first place. I will at least redo it
at some point (after Unicorn 1.x) to gain some
scalability/performance (and perhaps lose some portability).
 - SIGKILL and SIGSTOP are special, userspace has no mechanism
to block/catch/ignore those signals, so we rely on the master
process to deliver them.
More information about the mongrel-unicorn