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 10.1.1.4 opened a connection on Unicorn
and just let it sit idle there.  That somebody at 10.1.1.4 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
request.

-- 
Eric Wong


More information about the mongrel-unicorn mailing list