unicorn stuck in sched_yield after ERESTARTNOHAND

Eric Wong normalperson at yhbt.net
Wed Jun 1 12:48:01 EDT 2011

Bharanee Rathna <deepfryed at gmail.com> wrote:
> On Wed, Jun 1, 2011 at 9:48 AM, Eric Wong <normalperson at yhbt.net> wrote:
> > Bharanee Rathna <deepfryed at gmail.com> wrote:
> >> I'm encountering a weird error where the unicorn workers are stuck in
> >> a loop after hitting a 500 on the backend sinatra app.
> >
> > Also, what extensions are you using in your app?
> heaps of em. yajl, swift, rmagick, fastcaptcha, flock, nokogiri &
> curb.  except swift and curb none of the others would be touching the
> network.

So are any of them hitting Unicorn from a Unicorn worker itself?
This only happens when your app hits a 500?  I would not write
an app that does that, but if you do, be sure to shutdown any
open connections on a 500 (or avoid the error in the first place) ...

> >> strace at the point where it starts to go into a loop of death

Actually, the sched_yield() only started when you hit sent SIGINT.

> > What triggered SIGINT?
> not sure
> >
> > Actually, after many lines of sched_yield() in your gist, I can see it
> > does actually exit the process.  Did you kill it with SIGINT?  If so, I
> > see nothing wrong...
> yes i killed it after the worker looked stuck and wasn't responding for 30s

So you hit Ctrl-C (which sends SIGINT)?

So basically somebody from opened a connection on Unicorn
and just let it sit idle there.  That somebody at could've
been the worker that triggered the 500 (and forgot it had open
ccnnections)  or a third party that made a request but sit idle
because it couldn't handle the 500 which your Unicorn worker sent.

>From what I understand so far, it's not a Unicorn problem, but
something in your app.

Also, you wouldn't have this problem if nginx is in front of Unicorn
since nginx won't open a connection and sit idle before making a

Eric Wong

More information about the mongrel-unicorn mailing list