unicorn stuck in sched_yield after ERESTARTNOHAND
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
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
More information about the mongrel-unicorn