* Re: Unicorn behaving irrationally in production after a day
2013-05-10 13:00 2% Unicorn behaving irrationally in production after a day Bogdan Dumitru
@ 2013-05-10 14:33 0% ` Aaron Suggs
0 siblings, 0 replies; 200+ results
From: Aaron Suggs @ 2013-05-10 14:33 UTC (permalink / raw)
To: unicorn list
Unicorns are mythical creatures that always behave rationally. :)
This sounds like a bug in your application rather than unicorn. Are you using :memory_store as your Rails.cache? That would fit the symptoms you're describing, since the cache would not be shared across processes.
If so, the solution is to use a shared cache store, like memcache (or the file system cache while you're on a single server).
On May 10, 2013, at 9:00 AM, Bogdan Dumitru <dumbogdan@gmail.com> wrote:
> Hey guys,
>
> I'm new to Unicorn and have been running into a weird issue. I'm currently running a EC2 cluster with each machine having nginx with 4 unicorn workers. I'm deploying using rubber (https://github.com/rubber/rubber), and the unicorn.rb config is basically the GitHub unicorn config (as detailed here: https://github.com/blog/517-unicorn).
> Everything works fine when I deploy, but after half a day - 1 day the server behaves irrationally. The server is an api server for a mobile application so I can easily see some variables that, on request, have a certain value, but if I do some checking with the rails console (on the production machine) I get a different value (the correct one). This seams to me like a weird object caching situation. It all gets solved if I restart unicorn.
> I'm not sure what config information you guys might be interested in so I won't bloat this mail with anything but let me know if there's any questions I can answer.
>
> I hope somebody can point me in the right direction because I can't really make heads or tails of it.
> Cheers,
> -b
>
> PS: I've read about something similar happening when using memcached for object caching, in a previous version, but that isn't the case here.
>
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Unicorn behaving irrationally in production after a day
@ 2013-05-10 13:00 2% Bogdan Dumitru
2013-05-10 14:33 0% ` Aaron Suggs
0 siblings, 1 reply; 200+ results
From: Bogdan Dumitru @ 2013-05-10 13:00 UTC (permalink / raw)
To: mongrel-unicorn@rubyforge.org
Hey guys,
I'm new to Unicorn and have been running into a weird issue. I'm currently running a EC2 cluster with each machine having nginx with 4 unicorn workers. I'm deploying using rubber (https://github.com/rubber/rubber), and the unicorn.rb config is basically the GitHub unicorn config (as detailed here: https://github.com/blog/517-unicorn).
Everything works fine when I deploy, but after half a day - 1 day the server behaves irrationally. The server is an api server for a mobile application so I can easily see some variables that, on request, have a certain value, but if I do some checking with the rails console (on the production machine) I get a different value (the correct one). This seams to me like a weird object caching situation. It all gets solved if I restart unicorn.
I'm not sure what config information you guys might be interested in so I won't bloat this mail with anything but let me know if there's any questions I can answer.
I hope somebody can point me in the right direction because I can't really make heads or tails of it.
Cheers,
-b
PS: I've read about something similar happening when using memcached for object caching, in a previous version, but that isn't the case here.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: Worker Timeout Debugging
@ 2013-04-20 1:26 4% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2013-04-20 1:26 UTC (permalink / raw)
To: unicorn list
Bill Vieux <billv@yahoo.com> wrote:
> I am getting occasional worker timeouts for a Rails app hosted on
> Heroku. I have rack-timeout set at the top of the middleware with a
> shorter timeout than unicorn workers, but it is not firing for some
> reason.
Which version of Ruby is this and what C extensions are you using?
This is probably a buggy C extension which blocks the VM.
> Are there any recommended techniques to determine the call stack when
> the worker is reaped?
Not the call stack, but you can get the Rails endpoint regardless of
Ruby version:
Ensure your Rails logger is configured to log the PID at the start
of every request. (I think Rails logs parameters by default for
every request).
Match up the killed workers logging from unicorn to the PIDs that
started a request (but never logged a completion) in the Rails log.
> The solutions that come to mind for me seem to require running a
> customized build of unicorn. For example: start a script (e.g., gdb to
> attach and core dump the worker) before (or in place of) sending the
> SIGKILL.
If you're using Ruby 1.9 or later, maybe sending SIGBUS/SIGSEGV can work
to trigger a Ruby core dump.
Do not attempt to install SIGSEGV/BUS handler(s) via Ruby, Ruby 1.9
already handles those internally. Ruby 2.0.0 prevents trapping SEGV/BUS
with Ruby-level Signal#trap handlers, even.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 4%]
* [ANN] unicorn 4.6.1 - minor cleanups
@ 2013-02-21 8:50 3% Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2013-02-21 8:50 UTC (permalink / raw)
To: mongrel-unicorn
Changes:
Unicorn::Const::UNICORN_VERSION is now auto-generated from
GIT-VERSION-GEN and always correct. Minor cleanups for
hijacking.
* http://unicorn.bogomips.org/
* mongrel-unicorn@rubyforge.org
* git://bogomips.org/unicorn.git
* http://unicorn.bogomips.org/NEWS.atom.xml
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Changing Ruby version
2013-02-14 20:20 9% ` Eric Wong
@ 2013-02-14 21:35 6% ` Jérémy Lecour
0 siblings, 0 replies; 200+ results
From: Jérémy Lecour @ 2013-02-14 21:35 UTC (permalink / raw)
To: unicorn list
2013/2/14 Eric Wong <normalperson@yhbt.net>:
> What you're doing is switching between Ruby installations (to different
> paths). unicorn still supports this, but it's a little more involved
> and involves modifying START_CTX (and possibly ENV).
>
> The "upgrade" case is easiest when a new version of Ruby is installed
> over the old one (this is the common case for OS package managers
> (e.g. RPM/dpkg/ports)).
This kind of switch is rare enough, but If I have to do this
regularly, I'll eventually try that.
Thanks
--
Jérémy Lecour :
http://jeremy.wordpress.com - http://twitter.com/jlecour
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 6%]
* Re: Changing Ruby version
2013-02-14 14:10 11% Changing Ruby version Jérémy Lecour
@ 2013-02-14 20:20 9% ` Eric Wong
2013-02-14 21:35 6% ` Jérémy Lecour
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2013-02-14 20:20 UTC (permalink / raw)
To: unicorn list
Jérémy Lecour <jeremy.lecour@gmail.com> wrote:
> Hi,
>
> I'm using Unicorn with rbenv to have different Ruby versions between projects.
>
> This morning, I wanted to change the Ruby version used by an app.
> I've updated the content of .ruby-version, then sent a USR2 signal to
> the master process to restart Unicorn (as I always do).
>
> I've noticed that it was still using the "old" Ruby binary.
I'm not familiar with rbenv, but you need to use the same "unicorn"
executable script for both installations (changing the shebang (#!)
line will do.
Otherwise, you can tweak Unicorn::HttpServer::START_CTX
(ref: http://unicorn.bogomips.org/Unicorn/HttpServer.html )
> If I started a new irb console, the Ruby was correct.
This is probably because the shell you started irb from has the new
environment variables needed to find your new Ruby. unicorn was
started from a different parent shell/process which had different
environment variables.
You may also need to modify ENV in a before_exec hook if there are
other environment variables your app depends on which a different
Ruby installation would change.
> Then I thought that maybe the way forking works allows to change the
> version of Unicorn itself and everything "below", but not the Ruby
> binary.
>
> Am I right ?
> Is there a way to do a rolling restart and change the Ruby binary at
> the same time?
What you're doing is switching between Ruby installations (to different
paths). unicorn still supports this, but it's a little more involved
and involves modifying START_CTX (and possibly ENV).
The "upgrade" case is easiest when a new version of Ruby is installed
over the old one (this is the common case for OS package managers
(e.g. RPM/dpkg/ports)).
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 9%]
* Changing Ruby version
@ 2013-02-14 14:10 11% Jérémy Lecour
2013-02-14 20:20 9% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Jérémy Lecour @ 2013-02-14 14:10 UTC (permalink / raw)
To: Liste Unicorn
Hi,
I'm using Unicorn with rbenv to have different Ruby versions between projects.
This morning, I wanted to change the Ruby version used by an app.
I've updated the content of .ruby-version, then sent a USR2 signal to
the master process to restart Unicorn (as I always do).
I've noticed that it was still using the "old" Ruby binary.
If I started a new irb console, the Ruby was correct.
Then I thought that maybe the way forking works allows to change the
version of Unicorn itself and everything "below", but not the Ruby
binary.
Am I right ?
Is there a way to do a rolling restart and change the Ruby binary at
the same time?
thanks
--
Jérémy Lecour :
http://jeremy.wordpress.com - http://twitter.com/jlecour
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 11%]
* What's cooking in unicorn.git
@ 2013-02-09 1:16 3% Eric Wong
2013-02-09 1:16 15% ` [PATCH 1/2] http_request: remove FIXME for rack.version clarification Eric Wong
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2013-02-09 1:16 UTC (permalink / raw)
To: mongrel-unicorn
I've pushed out a few minor changes to master, nothing major.
git clone git://bogomips.org/unicorn.git
Eric Wong (3):
auto-generate Unicorn::Const::UNICORN_VERSION
http_request: remove FIXME for rack.version clarification
http_request: drop conditional assignment for hijack
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* [PATCH 1/2] http_request: remove FIXME for rack.version clarification
2013-02-09 1:16 3% What's cooking in unicorn.git Eric Wong
@ 2013-02-09 1:16 15% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2013-02-09 1:16 UTC (permalink / raw)
To: mongrel-unicorn
commit a9474624a148fe58e0944664190b259787dcf51e in rack.git
---
lib/unicorn/http_request.rb | 3 ---
1 file changed, 3 deletions(-)
diff --git a/lib/unicorn/http_request.rb b/lib/unicorn/http_request.rb
index 3795b3b..681c0ca 100644
--- a/lib/unicorn/http_request.rb
+++ b/lib/unicorn/http_request.rb
@@ -98,9 +98,6 @@ class Unicorn::HttpParser
# Rack 1.5.0 (protocol version 1.2) adds hijack request support
if ((Rack::VERSION[0] << 8) | Rack::VERSION[1]) >= 0x0102
DEFAULTS["rack.hijack?"] = true
-
- # FIXME: asking for clarification about this in
- # http://mid.gmane.org/20130122100802.GA28585@dcvr.yhbt.net
DEFAULTS["rack.version"] = [1, 2]
RACK_HIJACK = "rack.hijack".freeze
--
1.8.1.2.526.gf51a757
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 15%]
* [PATCH] auto-generate Unicorn::Const::UNICORN_VERSION
2013-02-08 13:54 6% Unicorn 4.6.0 version is 4.5.0 Maurizio De Santis
@ 2013-02-08 18:55 35% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2013-02-08 18:55 UTC (permalink / raw)
To: unicorn list; +Cc: Maurizio De Santis
Maurizio De Santis <m.desantis@morganspa.com> wrote:
> Hello,
>
> I want to report that unicorn-4.6.0/lib/unicorn/const.rb declares
> UNICORN_VERSION = "4.5.0", which I think should be "4.6.0".
Oops, I've been meaning to move that constant over to an auto-generated file
using GIT-VERSION-GEN. This should work:
--------------------------------- 8< ------------------------------
>From cb0623f25db7f06660e563e8e746bfe0ae5ba9c5 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Fri, 8 Feb 2013 18:50:07 +0000
Subject: [PATCH] auto-generate Unicorn::Const::UNICORN_VERSION
This DRYs out our code and prevents snafus like the 4.6.0
release where UNICORN_VERSION stayed at 4.5.0
Reported-by: Maurizio De Santis <m.desantis@morganspa.com>
---
.gitignore | 1 +
GIT-VERSION-GEN | 69 ++++++++++++++++++++++++++--------------------------
GNUmakefile | 2 +-
lib/unicorn/const.rb | 4 +--
4 files changed, 37 insertions(+), 39 deletions(-)
diff --git a/.gitignore b/.gitignore
index 50c2736..19a82d6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -22,3 +22,4 @@ pkg/
/man
/tmp
/LATEST
+/lib/unicorn/version.rb
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 56aef5f..e5d414a 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -1,40 +1,39 @@
-#!/bin/sh
-
-GVF=GIT-VERSION-FILE
-DEF_VER=v4.6.0
-
-LF='
-'
+#!/usr/bin/env ruby
+DEF_VER = "v4.6.0"
+CONSTANT = "Unicorn::Const::UNICORN_VERSION"
+RVF = "lib/unicorn/version.rb"
+GVF = "GIT-VERSION-FILE"
+vn = DEF_VER
# First see if there is a version file (included in release tarballs),
# then try git-describe, then default.
-if test -f version
-then
- VN=$(cat version) || VN="$DEF_VER"
-elif test -d .git -o -f .git &&
- VN=$(git describe --abbrev=4 HEAD 2>/dev/null) &&
- case "$VN" in
- *$LF*) (exit 1) ;;
- v[0-9]*)
- git update-index -q --refresh
- test -z "$(git diff-index --name-only HEAD --)" ||
- VN="$VN-dirty" ;;
- esac
-then
- VN=$(echo "$VN" | sed -e 's/-/./g');
-else
- VN="$DEF_VER"
-fi
+if File.exist?(".git")
+ describe = `git describe --abbrev=4 HEAD 2>/dev/null`.strip
+ case describe
+ when /\Av[0-9]*/
+ vn = describe
+ system(*%w(git update-index -q --refresh))
+ unless `git diff-index --name-only HEAD --`.chomp.empty?
+ vn << "-dirty"
+ end
+ vn.tr!('-', '.')
+ end
+end
+
+vn = vn.sub!(/\Av/, "")
+
+# generate the Ruby constant
+new_ruby_version = "#{CONSTANT} = '#{vn}'\n"
+cur_ruby_version = File.read(RVF) rescue nil
+if new_ruby_version != cur_ruby_version
+ File.open(RVF, "w") { |fp| fp.write(new_ruby_version) }
+end
-VN=$(expr "$VN" : v*'\(.*\)')
+# generate the makefile snippet
+new_make_version = "GIT_VERSION = #{vn}\n"
+cur_make_version = File.read(GVF) rescue nil
+if new_make_version != cur_make_version
+ File.open(GVF, "w") { |fp| fp.write(new_make_version) }
+end
-if test -r $GVF
-then
- VC=$(sed -e 's/^GIT_VERSION = //' <$GVF)
-else
- VC=unset
-fi
-test "$VN" = "$VC" || {
- echo >&2 "GIT_VERSION = $VN"
- echo "GIT_VERSION = $VN" >$GVF
-}
+puts vn if $0 == __FILE__
diff --git a/GNUmakefile b/GNUmakefile
index ea13486..34a2d95 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -155,7 +155,7 @@ clean:
man html:
$(MAKE) -C Documentation install-$@
-pkg_extra := GIT-VERSION-FILE ChangeLog LATEST NEWS \
+pkg_extra := GIT-VERSION-FILE lib/unicorn/version.rb ChangeLog LATEST NEWS \
$(ext)/unicorn_http.c $(man1_paths)
ChangeLog: GIT-VERSION-FILE .wrongdoc.yml
diff --git a/lib/unicorn/const.rb b/lib/unicorn/const.rb
index fcc30c0..51d7394 100644
--- a/lib/unicorn/const.rb
+++ b/lib/unicorn/const.rb
@@ -7,9 +7,6 @@
# improvement over using the strings directly. Symbols did not really
# improve things much compared to constants.
module Unicorn::Const
-
- UNICORN_VERSION = "4.5.0"
-
# default TCP listen host address (0.0.0.0, all interfaces)
DEFAULT_HOST = "0.0.0.0"
@@ -44,3 +41,4 @@ module Unicorn::Const
# :startdoc:
end
+require 'unicorn/version'
--
1.8.1.2.526.gf51a757
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 35%]
* Unicorn 4.6.0 version is 4.5.0
@ 2013-02-08 13:54 6% Maurizio De Santis
2013-02-08 18:55 35% ` [PATCH] auto-generate Unicorn::Const::UNICORN_VERSION Eric Wong
0 siblings, 1 reply; 200+ results
From: Maurizio De Santis @ 2013-02-08 13:54 UTC (permalink / raw)
To: mongrel-unicorn
Hello,
I want to report that unicorn-4.6.0/lib/unicorn/const.rb declares
UNICORN_VERSION = "4.5.0", which I think should be "4.6.0".
This made me swear at bundler and rbenv for one hour before to notice
the typo in the unicorn gem :-)
Best regards
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 6%]
* [ANN] unicorn 4.6.0pre1 - hijacking support!
@ 2013-01-29 21:10 20% Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2013-01-29 21:10 UTC (permalink / raw)
To: mongrel-unicorn
Installing from RubyGems.org: gem install --pre unicorn
>From db919d18e01f6b2339915cbd057fba9dc040988b Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Tue, 29 Jan 2013 21:02:55 +0000
Subject: [PATCH] unicorn 4.6.0pre1 - hijacking support
This pre-release adds hijacking support for Rack 1.5 users.
See Rack documentation for more information about hijacking.
There is also a new --no-default-middleware/-N option
for the `unicorn' command to ignore RACK_ENV within unicorn.
---
GIT-VERSION-GEN | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 365df8d..46ef417 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -1,7 +1,7 @@
#!/bin/sh
GVF=GIT-VERSION-FILE
-DEF_VER=v4.5.0
+DEF_VER=v4.6.0.pre1
LF='
'
--
1.8.1.1.253.g2934a48
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 20%]
* Re: SIGSEGV at shutdown (was: Re: your mail)
2013-01-24 9:52 0% ` Eric Wong
@ 2013-01-24 10:27 0% ` Charles Hornberger
0 siblings, 0 replies; 200+ results
From: Charles Hornberger @ 2013-01-24 10:27 UTC (permalink / raw)
To: unicorn list
On Thu, Jan 24, 2013 at 10:52 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Charles Hornberger <charles.hornberger@gmail.com> wrote:
>> On Mon, Jan 21, 2013 at 11:28 AM, Eric Wong <normalperson@yhbt.net> wrote:
>> > Charles Hornberger <charles.hornberger@gmail.com> wrote:
>> >> E, [2013-01-18T17:54:21.502915 #59285] ERROR -- : reaped
>> >> #<Process::Status: pid 59288 SIGSEGV (signal 11)> worker=1
>
> <snip>
>
>> >> I, [2013-01-18T17:54:21.605077 #59285] INFO -- : master complete
>> >>
>> >> Just wondering if it's something I should be concerned about? I saw no
>> >> obvious symptoms of problems before or after…
>> >>
>> >> We currently restart unicorn (which is on a freebsd jail) like so:
>> >
>> > A SEGV at shutdown is likely an ordering problem at VM shutdown
>> > (probably GC/finalization handling). It could be specific to the
>> > malloc/pthread implementation on FreeBSD, even.
>> >
>> > Which version of Ruby are you using?
>>
>> 1.9.3p-125
>
> Can you give 1.9.3-p374 a try? There were several GC-related segfault
> fixes along the way (fairly large and drastic changes, even).
We'll be moving to that soon. Since the problem has only occurred
*once* afaik, and there was nothing special that I can think of to do
to reproduce it, we may never know if the change fixed anything. :)
But if I happen to see it again, I will attempt to provide more info.
>
> <snip>
>
> Also, did you manage to get any backtrace from Ruby at all? The Ruby VM
> should show a partial stack trace on SEGV (or at least attempt to, but
> it may not during shutdown). Otherwise, you'd have to get gdb-able core
> dumps the old-fashioned way (ulimit -c unlimited) and show us (or
> ruby-core) the backtrace.
Nothing was emitted at the time -- what I sent before was all that
appeared in stderr.log.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: SIGSEGV at shutdown (was: Re: your mail)
2013-01-24 8:42 0% SIGSEGV at shutdown (was: Re: your mail) Charles Hornberger
@ 2013-01-24 9:52 0% ` Eric Wong
2013-01-24 10:27 0% ` Charles Hornberger
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2013-01-24 9:52 UTC (permalink / raw)
To: unicorn list
Charles Hornberger <charles.hornberger@gmail.com> wrote:
> On Mon, Jan 21, 2013 at 11:28 AM, Eric Wong <normalperson@yhbt.net> wrote:
> > Charles Hornberger <charles.hornberger@gmail.com> wrote:
> >> E, [2013-01-18T17:54:21.502915 #59285] ERROR -- : reaped
> >> #<Process::Status: pid 59288 SIGSEGV (signal 11)> worker=1
<snip>
> >> I, [2013-01-18T17:54:21.605077 #59285] INFO -- : master complete
> >>
> >> Just wondering if it's something I should be concerned about? I saw no
> >> obvious symptoms of problems before or after…
> >>
> >> We currently restart unicorn (which is on a freebsd jail) like so:
> >
> > A SEGV at shutdown is likely an ordering problem at VM shutdown
> > (probably GC/finalization handling). It could be specific to the
> > malloc/pthread implementation on FreeBSD, even.
> >
> > Which version of Ruby are you using?
>
> 1.9.3p-125
Can you give 1.9.3-p374 a try? There were several GC-related segfault
fixes along the way (fairly large and drastic changes, even).
<snip>
Nothing else jumps out at me (I remember nokogiri having a problem
which led to at least one GC bugfix shortly after p125).
Also, did you manage to get any backtrace from Ruby at all? The Ruby VM
should show a partial stack trace on SEGV (or at least attempt to, but
it may not during shutdown). Otherwise, you'd have to get gdb-able core
dumps the old-fashioned way (ulimit -c unlimited) and show us (or
ruby-core) the backtrace.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* SIGSEGV at shutdown (was: Re: your mail)
@ 2013-01-24 8:42 0% Charles Hornberger
2013-01-24 9:52 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Charles Hornberger @ 2013-01-24 8:42 UTC (permalink / raw)
To: unicorn list
On Mon, Jan 21, 2013 at 11:28 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Charles Hornberger <charles.hornberger@gmail.com> wrote:
>> Hi!
>>
>> I recently noticed this error message when restarting unicorn after a
>> code deployment (and I don't think I recall having seen it before):
>>
>> I, [2013-01-18T17:54:21.502554 #59285] INFO -- : reaped
>> #<Process::Status: pid 59293 exit 0> worker=6
>> I, [2013-01-18T17:54:21.502692 #59285] INFO -- : reaped
>> #<Process::Status: pid 59294 exit 0> worker=7
>> I, [2013-01-18T17:54:21.502754 #59285] INFO -- : reaped
>> #<Process::Status: pid 59292 exit 0> worker=5
>> I, [2013-01-18T17:54:21.502819 #59285] INFO -- : reaped
>> #<Process::Status: pid 59291 exit 0> worker=4
>> E, [2013-01-18T17:54:21.502915 #59285] ERROR -- : reaped
>> #<Process::Status: pid 59288 SIGSEGV (signal 11)> worker=1
>> I, [2013-01-18T17:54:21.502967 #59285] INFO -- : reaped
>> #<Process::Status: pid 59287 exit 0> worker=0
>> I, [2013-01-18T17:54:21.604829 #59285] INFO -- : reaped
>> #<Process::Status: pid 59290 exit 0> worker=3
>> I, [2013-01-18T17:54:21.604935 #59285] INFO -- : reaped
>> #<Process::Status: pid 59289 exit 0> worker=2
>> I, [2013-01-18T17:54:21.605077 #59285] INFO -- : master complete
>>
>> Just wondering if it's something I should be concerned about? I saw no
>> obvious symptoms of problems before or after…
>>
>> We currently restart unicorn (which is on a freebsd jail) like so:
>
> A SEGV at shutdown is likely an ordering problem at VM shutdown
> (probably GC/finalization handling). It could be specific to the
> malloc/pthread implementation on FreeBSD, even.
>
> Which version of Ruby are you using?
1.9.3p-125
> Which C extensions do you have loaded?
There's probably a better way to answer this question, but ...
% find vendor/bundle/ruby/1.9.1/gems -name '*.so'
vendor/bundle/ruby/1.9.1/gems/clogger-1.1.0/ext/clogger_ext/clogger_ext.so
vendor/bundle/ruby/1.9.1/gems/clogger-1.1.0/lib/clogger_ext.so
vendor/bundle/ruby/1.9.1/gems/eventmachine-1.0.0.rc.4/ext/fastfilereader/fastfilereaderext.so
vendor/bundle/ruby/1.9.1/gems/eventmachine-1.0.0.rc.4/ext/rubyeventmachine.so
vendor/bundle/ruby/1.9.1/gems/eventmachine-1.0.0.rc.4/lib/rubyeventmachine.so
vendor/bundle/ruby/1.9.1/gems/eventmachine-1.0.0.rc.4/lib/fastfilereaderext.so
vendor/bundle/ruby/1.9.1/gems/escape_utils-0.2.4/ext/escape_utils/escape_utils.so
vendor/bundle/ruby/1.9.1/gems/escape_utils-0.2.4/lib/escape_utils.so
vendor/bundle/ruby/1.9.1/gems/http_parser.rb-0.5.3/ext/ruby_http_parser/ruby_http_parser.so
vendor/bundle/ruby/1.9.1/gems/http_parser.rb-0.5.3/lib/ruby_http_parser.so
vendor/bundle/ruby/1.9.1/gems/json-1.7.4/ext/json/ext/generator/generator.so
vendor/bundle/ruby/1.9.1/gems/json-1.7.4/ext/json/ext/parser/parser.so
vendor/bundle/ruby/1.9.1/gems/json-1.7.4/lib/json/ext/generator.so
vendor/bundle/ruby/1.9.1/gems/json-1.7.4/lib/json/ext/parser.so
vendor/bundle/ruby/1.9.1/gems/kgio-2.7.4/ext/kgio/kgio_ext.so
vendor/bundle/ruby/1.9.1/gems/kgio-2.7.4/lib/kgio_ext.so
vendor/bundle/ruby/1.9.1/gems/raindrops-0.10.0/ext/raindrops/raindrops_ext.so
vendor/bundle/ruby/1.9.1/gems/raindrops-0.10.0/lib/raindrops_ext.so
vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/ext/unicorn_http/unicorn_http.so
vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn_http.so
vendor/bundle/ruby/1.9.1/gems/json-1.7.3/ext/json/ext/generator/generator.so
vendor/bundle/ruby/1.9.1/gems/json-1.7.3/ext/json/ext/parser/parser.so
vendor/bundle/ruby/1.9.1/gems/json-1.7.3/lib/json/ext/parser.so
vendor/bundle/ruby/1.9.1/gems/json-1.7.3/lib/json/ext/generator.so
vendor/bundle/ruby/1.9.1/gems/therubyracer-freebsd-0.10.1/ext/v8/v8.so
vendor/bundle/ruby/1.9.1/gems/therubyracer-freebsd-0.10.1/lib/v8.so
vendor/bundle/ruby/1.9.1/gems/lwes-0.8.3/ext/lwes_ext/lwes_ext.so
vendor/bundle/ruby/1.9.1/gems/lwes-0.8.3/lib/lwes_ext.so
vendor/bundle/ruby/1.9.1/gems/clogger-1.2.0/ext/clogger_ext/clogger_ext.so
vendor/bundle/ruby/1.9.1/gems/clogger-1.2.0/lib/clogger_ext.so
vendor/bundle/ruby/1.9.1/gems/eventmachine-1.0.0/ext/fastfilereader/fastfilereaderext.so
vendor/bundle/ruby/1.9.1/gems/eventmachine-1.0.0/ext/rubyeventmachine.so
vendor/bundle/ruby/1.9.1/gems/eventmachine-1.0.0/lib/rubyeventmachine.so
vendor/bundle/ruby/1.9.1/gems/eventmachine-1.0.0/lib/fastfilereaderext.so
vendor/bundle/ruby/1.9.1/gems/json-1.7.5/ext/json/ext/generator/generator.so
vendor/bundle/ruby/1.9.1/gems/json-1.7.5/ext/json/ext/parser/parser.so
vendor/bundle/ruby/1.9.1/gems/json-1.7.5/lib/json/ext/generator.so
vendor/bundle/ruby/1.9.1/gems/json-1.7.5/lib/json/ext/parser.so
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/ext/psych/psych.so
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych.so
vendor/bundle/ruby/1.9.1/gems/unicorn-4.5.0/ext/unicorn_http/unicorn_http.so
vendor/bundle/ruby/1.9.1/gems/unicorn-4.5.0/lib/unicorn_http.so
We use rvm, and afaik Ruby is installed w/ the "usual" rvm packages
(readline, iconv, openssl, zlib, autoconf).
> What at_exit/END handlers does your app have?
None
> What finalizers does your have?
None.
Thanks,
-c
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* [PATCH] support for Rack hijack in request and response
@ 2013-01-22 11:49 10% Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2013-01-22 11:49 UTC (permalink / raw)
To: mongrel-unicorn
Rack 1.5.0 (protocol version [1,2]) adds support for
hijacking the client socket (removing it from the control
of unicorn (or any other Rack webserver)).
Tested with rack 1.5.0.
---
I've pushed this to the "hijack" branch of git://bogomips.org/unicorn
As this is a development branch, I intend to rebase and cleanup history
as needed before it hits master.
I also believe the Rack::Lint change mentioned in my t0005 comment
below is a bug (patch/pull posted to rack-devel ML:
20130122113749.GA31589@dcvr.yhbt.net )
lib/unicorn/http_request.rb | 21 +++++++++++++++++++
lib/unicorn/http_response.rb | 40 +++++++++++++++++++++++++++++--------
lib/unicorn/http_server.rb | 6 ++++--
t/hijack.ru | 37 ++++++++++++++++++++++++++++++++++
t/t0005-working_directory_app.rb.sh | 5 ++++-
t/t0200-rack-hijack.sh | 27 +++++++++++++++++++++++++
6 files changed, 125 insertions(+), 11 deletions(-)
create mode 100644 t/hijack.ru
create mode 100755 t/t0200-rack-hijack.sh
diff --git a/lib/unicorn/http_request.rb b/lib/unicorn/http_request.rb
index 79ead2e..3bc64ed 100644
--- a/lib/unicorn/http_request.rb
+++ b/lib/unicorn/http_request.rb
@@ -91,6 +91,27 @@ class Unicorn::HttpParser
e[RACK_INPUT] = 0 == content_length ?
NULL_IO : @@input_class.new(socket, self)
+ hijack_setup(e, socket)
e.merge!(DEFAULTS)
end
+
+ # Rack 1.5.0 (protocol version 1.2) adds hijack request support
+ if ((Rack::VERSION[0] << 8) | Rack::VERSION[1]) >= 0x0102
+ DEFAULTS["rack.hijack?"] = true
+
+ # FIXME: asking for clarification about this in
+ # http://mid.gmane.org/20130122100802.GA28585@dcvr.yhbt.net
+ DEFAULTS["rack.version"] = [1, 2]
+
+ RACK_HIJACK = "rack.hijack".freeze
+ RACK_HIJACK_IO = "rack.hijack_io".freeze
+
+ def hijack_setup(e, socket)
+ e[RACK_HIJACK] = proc { e[RACK_HIJACK_IO] ||= socket }
+ end
+ else
+ # old Rack, do nothing.
+ def hijack_setup(e, _)
+ end
+ end
end
diff --git a/lib/unicorn/http_response.rb b/lib/unicorn/http_response.rb
index 579d957..083951c 100644
--- a/lib/unicorn/http_response.rb
+++ b/lib/unicorn/http_response.rb
@@ -25,6 +25,7 @@ module Unicorn::HttpResponse
def http_response_write(socket, status, headers, body,
response_start_sent=false)
status = CODES[status.to_i] || status
+ hijack = nil
http_response_start = response_start_sent ? '' : 'HTTP/1.1 '
if headers
@@ -33,19 +34,42 @@ module Unicorn::HttpResponse
"Status: #{status}\r\n" \
"Connection: close\r\n"
headers.each do |key, value|
- next if %r{\A(?:Date\z|Connection\z)}i =~ key
- if value =~ /\n/
- # avoiding blank, key-only cookies with /\n+/
- buf << value.split(/\n+/).map! { |v| "#{key}: #{v}\r\n" }.join
+ case key
+ when %r{\A(?:Date\z|Connection\z)}i
+ next
+ when "rack.hijack"
+ # this was an illegal key in Rack < 1.5, so it should be
+ # OK to silently discard it for those older versions
+ hijack = hijack_prepare(value)
else
- buf << "#{key}: #{value}\r\n"
+ if value =~ /\n/
+ # avoiding blank, key-only cookies with /\n+/
+ buf << value.split(/\n+/).map! { |v| "#{key}: #{v}\r\n" }.join
+ else
+ buf << "#{key}: #{value}\r\n"
+ end
end
end
socket.write(buf << CRLF)
end
- body.each { |chunk| socket.write(chunk) }
- ensure
- body.respond_to?(:close) and body.close
+ if hijack
+ body = nil # ensure we do not close body
+ hijack.call(socket)
+ else
+ body.each { |chunk| socket.write(chunk) }
+ end
+ ensure
+ body.respond_to?(:close) and body.close
+ end
+
+ # Rack 1.5.0 (protocol version 1.2) adds response hijacking support
+ if ((Rack::VERSION[0] << 8) | Rack::VERSION[1]) >= 0x0102
+ def hijack_prepare(value)
+ value
+ end
+ else
+ def hijack_prepare(_)
+ end
end
end
diff --git a/lib/unicorn/http_server.rb b/lib/unicorn/http_server.rb
index aa98aeb..2d8e4e1 100644
--- a/lib/unicorn/http_server.rb
+++ b/lib/unicorn/http_server.rb
@@ -559,8 +559,10 @@ class Unicorn::HttpServer
@request.headers? or headers = nil
http_response_write(client, status, headers, body,
@request.response_start_sent)
- client.shutdown # in case of fork() in Rack app
- client.close # flush and uncork socket immediately, no keepalive
+ unless client.closed? # rack.hijack may've close this for us
+ client.shutdown # in case of fork() in Rack app
+ client.close # flush and uncork socket immediately, no keepalive
+ end
rescue => e
handle_error(client, e)
end
diff --git a/t/hijack.ru b/t/hijack.ru
new file mode 100644
index 0000000..105e0d7
--- /dev/null
+++ b/t/hijack.ru
@@ -0,0 +1,37 @@
+use Rack::Lint
+use Rack::ContentLength
+use Rack::ContentType, "text/plain"
+class DieIfUsed
+ def each
+ abort "body.each called after response hijack\n"
+ end
+
+ def close
+ abort "body.close called after response hijack\n"
+ end
+end
+run lambda { |env|
+ case env["PATH_INFO"]
+ when "/hijack_req"
+ if env["rack.hijack?"]
+ io = env["rack.hijack"].call
+ if io.respond_to?(:read_nonblock) &&
+ env["rack.hijack_io"].respond_to?(:read_nonblock)
+ return [ 200, {}, [ "hijack.OK\n" ] ]
+ end
+ end
+ [ 500, {}, [ "hijack BAD\n" ] ]
+ when "/hijack_res"
+ r = "response.hijacked"
+ [ 200,
+ {
+ "Content-Length" => r.bytesize.to_s,
+ "rack.hijack" => proc do |io|
+ io.write(r)
+ io.close
+ end
+ },
+ DieIfUsed.new
+ ]
+ end
+}
diff --git a/t/t0005-working_directory_app.rb.sh b/t/t0005-working_directory_app.rb.sh
index 37c6fa7..0fbab4f 100755
--- a/t/t0005-working_directory_app.rb.sh
+++ b/t/t0005-working_directory_app.rb.sh
@@ -11,7 +11,10 @@ t_begin "setup and start" && {
cat > $t_pfx.app/fooapp.rb <<\EOF
class Fooapp
def self.call(env)
- [ 200, [%w(Content-Type text/plain), %w(Content-Length 2)], %w(HI) ]
+ # Rack::Lint in 1.5.0 requires headers to be a hash
+ h = [%w(Content-Type text/plain), %w(Content-Length 2)]
+ h = Rack::Utils::HeaderHash.new(h)
+ [ 200, h, %w(HI) ]
end
end
EOF
diff --git a/t/t0200-rack-hijack.sh b/t/t0200-rack-hijack.sh
new file mode 100755
index 0000000..23a9ee4
--- /dev/null
+++ b/t/t0200-rack-hijack.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+. ./test-lib.sh
+t_plan 5 "rack.hijack tests (Rack 1.5+ (Rack::VERSION >= [ 1,2]))"
+
+t_begin "setup and start" && {
+ unicorn_setup
+ unicorn -D -c $unicorn_config hijack.ru
+ unicorn_wait_start
+}
+
+t_begin "check request hijack" && {
+ test "xhijack.OK" = x"$(curl -sSfv http://$listen/hijack_req)"
+}
+
+t_begin "check response hijack" && {
+ test "xresponse.hijacked" = x"$(curl -sSfv http://$listen/hijack_res)"
+}
+
+t_begin "killing succeeds" && {
+ kill $unicorn_pid
+}
+
+t_begin "check stderr" && {
+ check_stderr
+}
+
+t_done
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 10%]
* Re: your mail
[not found] <CAKjxZvr-LJuY4LP4ZQa4yCs40SB8i2Y7N-hrgPxDxLc4uSM9Mg@mail.gmail.com>
@ 2013-01-21 10:28 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2013-01-21 10:28 UTC (permalink / raw)
To: unicorn list
Charles Hornberger <charles.hornberger@gmail.com> wrote:
> Hi!
>
> I recently noticed this error message when restarting unicorn after a
> code deployment (and I don't think I recall having seen it before):
>
> I, [2013-01-18T17:54:21.502554 #59285] INFO -- : reaped
> #<Process::Status: pid 59293 exit 0> worker=6
> I, [2013-01-18T17:54:21.502692 #59285] INFO -- : reaped
> #<Process::Status: pid 59294 exit 0> worker=7
> I, [2013-01-18T17:54:21.502754 #59285] INFO -- : reaped
> #<Process::Status: pid 59292 exit 0> worker=5
> I, [2013-01-18T17:54:21.502819 #59285] INFO -- : reaped
> #<Process::Status: pid 59291 exit 0> worker=4
> E, [2013-01-18T17:54:21.502915 #59285] ERROR -- : reaped
> #<Process::Status: pid 59288 SIGSEGV (signal 11)> worker=1
> I, [2013-01-18T17:54:21.502967 #59285] INFO -- : reaped
> #<Process::Status: pid 59287 exit 0> worker=0
> I, [2013-01-18T17:54:21.604829 #59285] INFO -- : reaped
> #<Process::Status: pid 59290 exit 0> worker=3
> I, [2013-01-18T17:54:21.604935 #59285] INFO -- : reaped
> #<Process::Status: pid 59289 exit 0> worker=2
> I, [2013-01-18T17:54:21.605077 #59285] INFO -- : master complete
>
> Just wondering if it's something I should be concerned about? I saw no
> obvious symptoms of problems before or after…
>
> We currently restart unicorn (which is on a freebsd jail) like so:
A SEGV at shutdown is likely an ordering problem at VM shutdown
(probably GC/finalization handling). It could be specific to the
malloc/pthread implementation on FreeBSD, even.
Which version of Ruby are you using?
Which C extensions do you have loaded?
What at_exit/END handlers does your app have?
What finalizers does your have?
Probably not a major issue as long as you don't have SEGVs at normal
runtime, but still annoying to see. IIRC, there have been a couple of
these bugs fixed by ruby-core over the years.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: preload_app = true causing - ActiveModel::MissingAttributeError: missing attribute: some_attr
@ 2013-01-21 8:11 3% ` Lawrence Pit
0 siblings, 0 replies; 200+ results
From: Lawrence Pit @ 2013-01-21 8:11 UTC (permalink / raw)
To: unicorn list
> That being said, I'm extremely surprised there is no published unicorn
> startup scripts that consider the common use case of a deployment
> stack that includes:
> Rails + Active Record
> Redis
> Memcache
http://unicorn.bogomips.org/examples/unicorn.conf.rb
In the after_fork you want:
Rails.cache.reset
or if you're using an older version of the memcache gem (i.e. you're not
using the dalli gem which I highly recommend) you may need this hack:
if Rails.cache.is_a?(ActiveSupport::Cache::MemCacheStore)
Rails.cache.instance_variable_get(:@data).reset
end
If you use the UUID gem you need this in your after_fork:
UUID.generator.next_sequence
As for redis:
https://github.com/redis/redis-rb/blob/master/examples/unicorn/unicorn.rb
Cheers,
Lawrence
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Unicorn fails to install even though it's already installed and running
@ 2012-12-06 21:54 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2012-12-06 21:54 UTC (permalink / raw)
To: unicorn list
Mac Martine <99miles@gmail.com> wrote:
> Thanks,
>
> I can install other gems just fine in the same way, so it doesn't seem
> like permissions then, right?
>
> And disk space looks ok:
That's good to know.
> Here's the end of mkmf.log
>
> have_macro: checking for SIZEOF_SIZE_T in ruby.h... -------------------- no
>
> "gcc -I. -I/usr/lib/ruby/1.8/x86_64-linux -I. -fno-strict-aliasing -g -g -O2 -fPIC -c conftest.c"
Wait, are you now using a different version of Ruby? Your original
message had 1.9 (via RVM)
> >> ** [out :: mydomain.net] Results logged to /rails_apps/eg/production/shared/bundle/ruby/1.9.1/gems/unicorn-4.4.0/ext/unicorn_http/gem_make.out
> >
> > Maybe gem_make.out will have more info than mkmf.log
Again ^^
However, scrutinizing your original email more:
> >> "gcc -I/home/evergreen/.rvm/rubies/ruby-1.9.3-p194/include/ruby-1.9.1/x86_64-linux -I/home/eg/.rvm/rubies/ruby-1.9.3-p194/include/ruby-1.9.1/ruby/backward -I/home/eg/.rvm/rubies/ruby-1.9.3-p194/include/ruby-1.9.1 -I. -I/home/eg/.rvm/usr/include -O3 -ggdb -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration -fPIC -c conftest.c"
I see both /home/evergreen/ and /home/eg/ in there; that looks
suspicious.
Did you perhaps copy anything in .rvm/ between home
directories or rename the home directory at some point after
RVM was installed?
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Issue starting unicorn with non-ActiveRecord Rails app
2012-12-05 5:19 2% ` Fwd: Issue starting unicorn with non-ActiveRecord Rails app Peter Hall
2012-12-05 7:45 3% ` Eric Wong
@ 2012-12-05 7:48 0% ` Daniel Condomitti
1 sibling, 0 replies; 200+ results
From: Daniel Condomitti @ 2012-12-05 7:48 UTC (permalink / raw)
To: unicorn list
On Tuesday, December 4, 2012 at 9:19 PM, Peter Hall wrote:
> Hi,
>
> I'm trying to use unicorn in a test deployment of a Rails app that
> uses Mongoid, so Activerecord isn't included in the app. When I start
> unicorn through Capistrano though, the stderr log fills up endlessly
> with identical ActiveRecord-related errors:
>
> I, [2012-12-05T04:19:25.375952 #5096] INFO -- : Refreshing Gem list
> I, [2012-12-05T04:19:32.941249 #5096] INFO -- : listening on
> addr=/var/www/webapps/fugu-cp/shared/pids/unicorn.sock fd=11
> I, [2012-12-05T04:19:32.990825 #5096] INFO -- : master process ready
> E, [2012-12-05T04:19:33.108183 #5110] ERROR -- : uninitialized
> constant ActiveRecord (NameError)
> /var/www/webapps/fugu-cp/current/config/unicorn.rb:68:in `block in reload'
> /var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/gems/unicorn-4.4.0/lib/unicorn/http_server.rb:569:in
> `call'
> /var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/gems/unicorn-4.4.0/lib/unicorn/http_server.rb:569:in
> `init_worker_process'
> /var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/gems/unicorn-4.4.0/lib/unicorn/http_server.rb:593:in
> `worker_loop'
> /var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/gems/unicorn-4.4.0/lib/unicorn/http_server.rb:491:in
> `spawn_missing_workers'
> /var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/gems/unicorn-4.4.0/lib/unicorn/http_server.rb:141:in
> `start'
> /var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/gems/unicorn-4.4.0/bin/unicorn_rails:209:in
> `<top (required)>'
> /var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/bin/unicorn_rails:23:in `load'
> /var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/bin/unicorn_rails:23:in
> `<main>'
>
> This repeats until I kill Unicorn.
>
> If you're curious, the way I'm starting Unicorn in the deploy file is
> as follows:
>
> set :unicorn_rails, "#{deploy_to}/shared/bundle/ruby/1.9.1/bin/unicorn_rails"
> run "cd #{latest_release} && bundle exec \"#{unicorn_rails} -c
> #{deploy_to}/current/config/unicorn.rb -D -E #{rails_env}\""
>
> Incidentally, if there's a standard Unicorn include file for
> Capistrano so I don't have to specify my own tasks to start and stop
> it, I'd be grateful to know, because I couldn't find one and had to
> use a very heavily-modified version of something I copied+pasted from
> this gist: https://gist.github.com/1003099
>
> Thanks,
What's L68 of your config/unicorn.rb file look like? Check to see if you have copied/pasted a line that references ActiveRecord in the before_fork or after_fork blocks.
A lot of unicorn examples have an ActiveRecord::Base.connection.disconnect! (with a defined?(ActiveRecord::Base) but that might not be present in your config) statement to ensure that AR connections aren't shared between the master and worker processes.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Fwd: Issue starting unicorn with non-ActiveRecord Rails app
2012-12-05 5:19 2% ` Fwd: Issue starting unicorn with non-ActiveRecord Rails app Peter Hall
@ 2012-12-05 7:45 3% ` Eric Wong
2012-12-05 7:48 0% ` Daniel Condomitti
1 sibling, 0 replies; 200+ results
From: Eric Wong @ 2012-12-05 7:45 UTC (permalink / raw)
To: unicorn list
Peter Hall <peter.hall@localstars.com> wrote:
> Hi,
>
> I'm trying to use unicorn in a test deployment of a Rails app that
> uses Mongoid, so Activerecord isn't included in the app. When I start
> unicorn through Capistrano though, the stderr log fills up endlessly
> with identical ActiveRecord-related errors:
>
> I, [2012-12-05T04:19:25.375952 #5096] INFO -- : Refreshing Gem list
> I, [2012-12-05T04:19:32.941249 #5096] INFO -- : listening on
> addr=/var/www/webapps/fugu-cp/shared/pids/unicorn.sock fd=11
> I, [2012-12-05T04:19:32.990825 #5096] INFO -- : master process ready
> E, [2012-12-05T04:19:33.108183 #5110] ERROR -- : uninitialized
> constant ActiveRecord (NameError)
Hi Peter, this doesn't seem like an issue specific to unicorn...
Can you reproduce this issue using another server, perhaps:
rackup -s webrick -E #{rails_env}
?
<snip>
> This repeats until I kill Unicorn.
>
> If you're curious, the way I'm starting Unicorn in the deploy file is
> as follows:
Which version of Rails is this? Folks more familiar with modern Rails
than myself should be able to help given more information. (Maybe
asking on a Rails-oriented list can help, too).
I do remember it was possible to disable parts of Rails back in the day.
Most of my Rails knowledge is stuck in the Rails 1.x-era, though...
> set :unicorn_rails, "#{deploy_to}/shared/bundle/ruby/1.9.1/bin/unicorn_rails"
> run "cd #{latest_release} && bundle exec \"#{unicorn_rails} -c
> #{deploy_to}/current/config/unicorn.rb -D -E #{rails_env}\""
Probably unrelated to the issue at hand, but "unicorn" is
preferred if you're on Rails >=3.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Fwd: Issue starting unicorn with non-ActiveRecord Rails app
[not found] <CA+c-+BYTxv+5mQ2MKeKVYEoxgPbi2QjwY6Oak-R_g65GhixEzg@mail.gmail.com>
@ 2012-12-05 5:19 2% ` Peter Hall
2012-12-05 7:45 3% ` Eric Wong
2012-12-05 7:48 0% ` Daniel Condomitti
0 siblings, 2 replies; 200+ results
From: Peter Hall @ 2012-12-05 5:19 UTC (permalink / raw)
To: mongrel-unicorn
Hi,
I'm trying to use unicorn in a test deployment of a Rails app that
uses Mongoid, so Activerecord isn't included in the app. When I start
unicorn through Capistrano though, the stderr log fills up endlessly
with identical ActiveRecord-related errors:
I, [2012-12-05T04:19:25.375952 #5096] INFO -- : Refreshing Gem list
I, [2012-12-05T04:19:32.941249 #5096] INFO -- : listening on
addr=/var/www/webapps/fugu-cp/shared/pids/unicorn.sock fd=11
I, [2012-12-05T04:19:32.990825 #5096] INFO -- : master process ready
E, [2012-12-05T04:19:33.108183 #5110] ERROR -- : uninitialized
constant ActiveRecord (NameError)
/var/www/webapps/fugu-cp/current/config/unicorn.rb:68:in `block in reload'
/var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/gems/unicorn-4.4.0/lib/unicorn/http_server.rb:569:in
`call'
/var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/gems/unicorn-4.4.0/lib/unicorn/http_server.rb:569:in
`init_worker_process'
/var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/gems/unicorn-4.4.0/lib/unicorn/http_server.rb:593:in
`worker_loop'
/var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/gems/unicorn-4.4.0/lib/unicorn/http_server.rb:491:in
`spawn_missing_workers'
/var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/gems/unicorn-4.4.0/lib/unicorn/http_server.rb:141:in
`start'
/var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/gems/unicorn-4.4.0/bin/unicorn_rails:209:in
`<top (required)>'
/var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/bin/unicorn_rails:23:in `load'
/var/www/webapps/fugu-cp/shared/bundle/ruby/1.9.1/bin/unicorn_rails:23:in
`<main>'
This repeats until I kill Unicorn.
If you're curious, the way I'm starting Unicorn in the deploy file is
as follows:
set :unicorn_rails, "#{deploy_to}/shared/bundle/ruby/1.9.1/bin/unicorn_rails"
run "cd #{latest_release} && bundle exec \"#{unicorn_rails} -c
#{deploy_to}/current/config/unicorn.rb -D -E #{rails_env}\""
Incidentally, if there's a standard Unicorn include file for
Capistrano so I don't have to specify my own tasks to start and stop
it, I'd be grateful to know, because I couldn't find one and had to
use a very heavily-modified version of something I copied+pasted from
this gist: https://gist.github.com/1003099
Thanks,
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: When a client terminates a connection
@ 2012-12-03 14:42 3% ` Andrew Stewart
0 siblings, 0 replies; 200+ results
From: Andrew Stewart @ 2012-12-03 14:42 UTC (permalink / raw)
To: unicorn list
On 30 Nov 2012, at 20:26, Eric Wong wrote:
>> Nginx logged:
>>
>> x.xxx.xx.xx - - [27/Nov/2012:14:40:28 +0000] "POST /clients/2248 HTTP/1.1" 499 0 "https://example.com/clients/2248/edit" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)"
>> x.xxx.xx.xx - - [27/Nov/2012:14:40:29 +0000] "POST /clients/2248 HTTP/1.1" 404 592 "https://example.com/companies/2248/edit" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)"
>>
>> You can see the first request was terminated by the user. Hot on its
>> heels the user tried again and got a 404.
>
> Weird, and this is the only nginx instance that saw this request?
That's right, I only run a single nginx worker process.
> Also, according to your logs above, the two requests above came from
> different Referer pages, so perhaps there were more requests involved
> that hit a different nginx?
Bizarre as it sounds, that was a copy-paste mistake on my part. The second referrer should read: "https://example.com/clients/2248/edit".
> Odd. It's been a long time since I looked at Rails; but doesn't Rails
> log when a request _starts_? Also, doesn't Rails log all DB queries?
I think Rails logs when a request starts, then logs some more when the request ends – but I'm not certain and I couldn't find the answer when I looked in the Rails source. It must be there somewhere.
Rails doesn't log the DB queries in production, at least not by default.
> Or, by any chance, do you have query logging enabled in your DB to track
> this down?
Regrettably not.
It's a weird problem which I'd like to dismiss, but it's happened on two occasions now. I'm running an old version of Rails (3.0.12) which may or may not be relevant. Hmm.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Combating nginx 499 HTTP responses during flash traffic scenario
2012-11-29 15:52 3% ` Tom Burns
@ 2012-11-29 20:41 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2012-11-29 20:41 UTC (permalink / raw)
To: unicorn list
Tom Burns <tom.burns@jadedpixel.com> wrote:
> So we just finished the US Black Friday / Cyber Monday weekend running
> unicorn forked with the last version of the patch I had sent you. It
> worked splendidly and helped us handle huge flash sales without
> increased response time over the weekend.
>
> Whereas in previous flash traffic scenarios we would see the number of
> HTTP 499 responses grow past the number of real HTTP 200 responses,
> over the weekend we saw no growth in 499s during flash sales.
>
> Unexpectedly the patch also helped us ward off a DoS attack where the
> attackers were disconnecting immediately after making a request.
That is absolutely wonderful to hear. I've amended your commit message
with the above quoted portion.
> I've attached the patch again, with your last comments addressed. Let
> me know if there's anything else.
>
> Thanks again for your help in this matter.
Thank _you_ for the patch, documentation and most importantly:
testing with real traffic.
I fixed up some minor line-wrapping, signed-off, and added your
quote above to the commit message. Pushed as
commit 5c700fc2cf398848ddcf71a2aa3f0f2a6563e87b
to git://bogomips.org/unicorn.git
I'll tag and push a 4.5.0.preview1 gem soon
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Combating nginx 499 HTTP responses during flash traffic scenario
2012-11-06 21:23 0% ` Eric Wong
@ 2012-11-29 15:52 3% ` Tom Burns
2012-11-29 20:41 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Tom Burns @ 2012-11-29 15:52 UTC (permalink / raw)
To: unicorn list
On Tue, Nov 6, 2012 at 4:23 PM, Eric Wong <normalperson@yhbt.net> wrote:
>
> Tom Burns <tom.burns@jadedpixel.com> wrote:
> > On Mon, Nov 5, 2012 at 6:48 AM, Eric Wong <normalperson@yhbt.net> wrote:
> > > We can wait until you can report on how this change improves your
> > > situation before fleshing this out. Real-world results are always
> > > good to have :>
> >
> > Agreed.
> >
> > We're going to be testing this this week so I should have some results
> > to share by the weekend. We only experience the problem during major
> > sales so it may or may not manifest without our traffic generation
> > tool.
>
> Holidays are coming up, should be lots of traffic :)
So we just finished the US Black Friday / Cyber Monday weekend running
unicorn forked with the last version of the patch I had sent you. It
worked splendidly and helped us handle huge flash sales without
increased response time over the weekend.
Whereas in previous flash traffic scenarios we would see the number of
HTTP 499 responses grow past the number of real HTTP 200 responses,
over the weekend we saw no growth in 499s during flash sales.
Unexpectedly the patch also helped us ward off a DoS attack where the
attackers were disconnecting immediately after making a request.
I've attached the patch again, with your last comments addressed. Let
me know if there's anything else.
Thanks again for your help in this matter.
Cheers,
Tom
>From 89c8c51355c75b0196469812580443fba390632e Mon Sep 17 00:00:00 2001
From: Tom Burns <tom.burns@jadedpixel.com>
Date: Tue, 30 Oct 2012 16:22:21 -0400
Subject: [PATCH] Begin writing HTTP request headers early to detect
disconnected clients
This patch checks incoming connections and avoids calling the application
if the connection has been closed.
It works by sending the beginning of the HTTP response before calling
the application to see if the socket can successfully be written to.
By enabling this feature users can avoid wasting application rendering
time only to find the connection is closed when attempting to write, and
throwing out the result.
When a client disconnects while being queued or processed, Nginx will log
HTTP response 499 but the application will log a 200.
Enabling this feature will minimize the time window during which the problem
can arise.
The feature is disabled by default and can be enabled by adding
'check_client_connection true' to the unicorn config.
---
examples/unicorn.conf.rb | 6 ++++++
ext/unicorn_http/unicorn_http.rl | 4 +++-
lib/unicorn/configurator.rb | 25 +++++++++++++++++++++++++
lib/unicorn/const.rb | 12 ++++++++----
lib/unicorn/http_request.rb | 19 +++++++++++++++++++
lib/unicorn/http_response.rb | 5 +++--
lib/unicorn/http_server.rb | 22 ++++++++++++++++++++--
test/exec/test_exec.rb | 7 ++++++-
test/unit/test_configurator.rb | 24 ++++++++++++++++++++++++
9 files changed, 114 insertions(+), 10 deletions(-)
diff --git a/examples/unicorn.conf.rb b/examples/unicorn.conf.rb
index 0238043..1f4c9c0 100644
--- a/examples/unicorn.conf.rb
+++ b/examples/unicorn.conf.rb
@@ -46,6 +46,12 @@ preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
GC.copy_on_write_friendly = true
+# Enable this flag to have unicorn test client connections by writing the
+# beginning of the HTTP headers before calling the application. This
+# prevents calling the application for connections that have disconnected
+# while queued.
+check_client_connection false
+
before_fork do |server, worker|
# the following is highly recomended for Rails + "preload_app true"
# as there's no need for the master process to hold a connection
diff --git a/ext/unicorn_http/unicorn_http.rl b/ext/unicorn_http/unicorn_http.rl
index 96dcf83..1a8003f 100644
--- a/ext/unicorn_http/unicorn_http.rl
+++ b/ext/unicorn_http/unicorn_http.rl
@@ -115,7 +115,7 @@ struct http_parser {
} len;
};
-static ID id_clear, id_set_backtrace;
+static ID id_clear, id_set_backtrace, id_response_start_sent;
static void finalize_header(struct http_parser *hp);
@@ -626,6 +626,7 @@ static VALUE HttpParser_clear(VALUE self)
http_parser_init(hp);
rb_funcall(hp->env, id_clear, 0);
+ rb_ivar_set(self, id_response_start_sent, Qfalse);
return self;
}
@@ -1031,6 +1032,7 @@ void Init_unicorn_http(void)
SET_GLOBAL(g_http_connection, "CONNECTION");
id_clear = rb_intern("clear");
id_set_backtrace = rb_intern("set_backtrace");
+ id_response_start_sent = rb_intern("@response_start_sent");
init_unicorn_httpdate();
}
#undef SET_GLOBAL
diff --git a/lib/unicorn/configurator.rb b/lib/unicorn/configurator.rb
index 89cbf5c..9752cdd 100644
--- a/lib/unicorn/configurator.rb
+++ b/lib/unicorn/configurator.rb
@@ -45,6 +45,7 @@ class Unicorn::Configurator
},
:pid => nil,
:preload_app => false,
+ :check_client_connection => false,
:rewindable_input => true, # for Rack 2.x: (Rack::VERSION[0] <= 1),
:client_body_buffer_size => Unicorn::Const::MAX_BODY,
:trust_x_forwarded => true,
@@ -96,6 +97,18 @@ class Unicorn::Configurator
if ready_pipe = RACKUP.delete(:ready_pipe)
server.ready_pipe = ready_pipe
end
+ if set[:check_client_connection]
+ set[:listeners].each do |address|
+ if set[:listener_opts][address][:tcp_nopush] == true
+ raise ArgumentError,
+ "check_client_connection is incompatible with tcp_nopush:true"
+ end
+ if set[:listener_opts][address][:tcp_nodelay] == true
+ raise ArgumentError,
+ "check_client_connection is incompatible with tcp_nodelay:true"
+ end
+ end
+ end
set.each do |key, value|
value == :unset and next
skip.include?(key) and next
@@ -454,6 +467,18 @@ class Unicorn::Configurator
set_int(:client_body_buffer_size, bytes, 0)
end
+ # When enabled, unicorn will check the client connection by writing
+ # the beginning of the HTTP headers before calling the application.
+ #
+ # This will prevent calling the application for clients who have
+ # disconnected while their connection was queued.
+ #
+ # This option cannot be used in conjunction with tcp_nodelay or
+ # tcp_nopush.
+ def check_client_connection(bool)
+ set_bool(:check_client_connection, bool)
+ end
+
# Allow redirecting $stderr to a given path. Unlike doing this from
# the shell, this allows the unicorn process to know the path its
# writing to and rotate the file if it is used for logging. The
diff --git a/lib/unicorn/const.rb b/lib/unicorn/const.rb
index b3d8d71..f0c4c12 100644
--- a/lib/unicorn/const.rb
+++ b/lib/unicorn/const.rb
@@ -29,12 +29,16 @@ module Unicorn::Const
# :stopdoc:
# common errors we'll send back
- ERROR_400_RESPONSE = "HTTP/1.1 400 Bad Request\r\n\r\n"
- ERROR_414_RESPONSE = "HTTP/1.1 414 Request-URI Too Long\r\n\r\n"
- ERROR_413_RESPONSE = "HTTP/1.1 413 Request Entity Too Large\r\n\r\n"
- ERROR_500_RESPONSE = "HTTP/1.1 500 Internal Server Error\r\n\r\n"
+ ERROR_400_RESPONSE = "400 Bad Request\r\n\r\n"
+ ERROR_414_RESPONSE = "414 Request-URI Too Long\r\n\r\n"
+ ERROR_413_RESPONSE = "413 Request Entity Too Large\r\n\r\n"
+ ERROR_500_RESPONSE = "500 Internal Server Error\r\n\r\n"
+
EXPECT_100_RESPONSE = "HTTP/1.1 100 Continue\r\n\r\n"
+ EXPECT_100_RESPONSE_SUFFIXED = "100 Continue\r\n\r\nHTTP/1.1 "
+ HTTP_RESPONSE_START = ['HTTP', '/1.1 ']
HTTP_EXPECT = "HTTP_EXPECT"
+
# :startdoc:
end
diff --git a/lib/unicorn/http_request.rb b/lib/unicorn/http_request.rb
index a0435d6..79ead2e 100644
--- a/lib/unicorn/http_request.rb
+++ b/lib/unicorn/http_request.rb
@@ -22,11 +22,14 @@ class Unicorn::HttpParser
NULL_IO = StringIO.new("")
+ attr_accessor :response_start_sent
+
# :stopdoc:
# A frozen format for this is about 15% faster
REMOTE_ADDR = 'REMOTE_ADDR'.freeze
RACK_INPUT = 'rack.input'.freeze
@@input_class = Unicorn::TeeInput
+ @@check_client_connection = false
def self.input_class
@@input_class
@@ -35,6 +38,15 @@ class Unicorn::HttpParser
def self.input_class=(klass)
@@input_class = klass
end
+
+ def self.check_client_connection
+ @@check_client_connection
+ end
+
+ def self.check_client_connection=(bool)
+ @@check_client_connection = bool
+ end
+
# :startdoc:
# Does the majority of the IO processing. It has been written in
@@ -70,6 +82,13 @@ class Unicorn::HttpParser
# an Exception thrown from the parser will throw us out of the loop
false until add_parse(socket.kgio_read!(16384))
end
+
+ # detect if the socket is valid by writing a partial response:
+ if @@check_client_connection && headers?
+ @response_start_sent = true
+ Unicorn::Const::HTTP_RESPONSE_START.each { |c| socket.write(c) }
+ end
+
e[RACK_INPUT] = 0 == content_length ?
NULL_IO : @@input_class.new(socket, self)
e.merge!(DEFAULTS)
diff --git a/lib/unicorn/http_response.rb b/lib/unicorn/http_response.rb
index b781e20..9c2bacc 100644
--- a/lib/unicorn/http_response.rb
+++ b/lib/unicorn/http_response.rb
@@ -18,11 +18,12 @@ module Unicorn::HttpResponse
CRLF = "\r\n"
# writes the rack_response to socket as an HTTP response
- def http_response_write(socket, status, headers, body)
+ def http_response_write(socket, status, headers, body,
response_start_sent=false)
status = CODES[status.to_i] || status
+ http_response_start = response_start_sent ? '' : 'HTTP/1.1 '
if headers
- buf = "HTTP/1.1 #{status}\r\n" \
+ buf = "#{http_response_start}#{status}\r\n" \
"Date: #{httpdate}\r\n" \
"Status: #{status}\r\n" \
"Connection: close\r\n"
diff --git a/lib/unicorn/http_server.rb b/lib/unicorn/http_server.rb
index 13df55a..8729830 100644
--- a/lib/unicorn/http_server.rb
+++ b/lib/unicorn/http_server.rb
@@ -17,6 +17,7 @@ class Unicorn::HttpServer
:listener_opts, :preload_app,
:reexec_pid, :orig_app, :init_listeners,
:master_pid, :config, :ready_pipe, :user
+
attr_reader :pid, :logger
include Unicorn::SocketHelper
include Unicorn::HttpResponse
@@ -355,6 +356,14 @@ class Unicorn::HttpServer
Unicorn::HttpParser.trust_x_forwarded = bool
end
+ def check_client_connection
+ Unicorn::HttpRequest.check_client_connection
+ end
+
+ def check_client_connection=(bool)
+ Unicorn::HttpRequest.check_client_connection = bool
+ end
+
private
# wait for a signal hander to wake us up and then consume the pipe
@@ -524,23 +533,32 @@ class Unicorn::HttpServer
Unicorn.log_error(@logger, "app error", e)
Unicorn::Const::ERROR_500_RESPONSE
end
+ msg = "HTTP/1.1 #{msg}" unless @request.response_start_sent
client.kgio_trywrite(msg)
client.close
rescue
end
+ def expect_100_response
+ if @request.response_start_sent
+ Unicorn::Const::EXPECT_100_RESPONSE_SUFFIXED
+ else
+ Unicorn::Const::EXPECT_100_RESPONSE
+ end
+ end
+
# once a client is accepted, it is processed in its entirety here
# in 3 easy steps: read request, call app, write app response
def process_client(client)
status, headers, body = @app.call(env = @request.read(client))
if 100 == status.to_i
- client.write(Unicorn::Const::EXPECT_100_RESPONSE)
+ client.write(expect_100_response)
env.delete(Unicorn::Const::HTTP_EXPECT)
status, headers, body = @app.call(env)
end
@request.headers? or headers = nil
- http_response_write(client, status, headers, body)
+ http_response_write(client, status, headers, body,
@request.response_start_sent)
client.shutdown # in case of fork() in Rack app
client.close # flush and uncork socket immediately, no keepalive
rescue => e
diff --git a/test/exec/test_exec.rb b/test/exec/test_exec.rb
index b30a3d6..1cee2b7 100644
--- a/test/exec/test_exec.rb
+++ b/test/exec/test_exec.rb
@@ -871,13 +871,14 @@ EOF
wait_for_death(pid)
end
- def hup_test_common(preload)
+ def hup_test_common(preload, check_client=false)
File.open("config.ru", "wb") { |fp| fp.syswrite(HI.gsub("HI", '#$$')) }
pid_file = Tempfile.new('pid')
ucfg = Tempfile.new('unicorn_test_config')
ucfg.syswrite("listen '#@addr:#@port'\n")
ucfg.syswrite("pid '#{pid_file.path}'\n")
ucfg.syswrite("preload_app true\n") if preload
+ ucfg.syswrite("check_client_connection true\n") if check_client
ucfg.syswrite("stderr_path 'test_stderr.#$$.log'\n")
ucfg.syswrite("stdout_path 'test_stdout.#$$.log'\n")
pid = xfork {
@@ -942,6 +943,10 @@ EOF
hup_test_common(false)
end
+ def test_check_client_hup
+ hup_test_common(false, true)
+ end
+
def test_default_listen_hup_holds_listener
default_listen_lock do
res, pid_path = default_listen_setup
diff --git a/test/unit/test_configurator.rb b/test/unit/test_configurator.rb
index c19c427..b9c22d7 100644
--- a/test/unit/test_configurator.rb
+++ b/test/unit/test_configurator.rb
@@ -139,6 +139,30 @@ class TestConfigurator < Test::Unit::TestCase
end
end
+ def test_check_client_connection
+ tmp = Tempfile.new('unicorn_config')
+ test_struct = TestStruct.new
+ tmp.syswrite("check_client_connection true\n")
+
+ assert_nothing_raised do
+ Unicorn::Configurator.new(:config_file => tmp.path).commit!(test_struct)
+ end
+
+ assert test_struct.check_client_connection
+ end
+
+ def test_check_client_connection_with_tcp_bad
+ tmp = Tempfile.new('unicorn_config')
+ test_struct = TestStruct.new
+ listener = "127.0.0.1:12345"
+ tmp.syswrite("check_client_connection true\n")
+ tmp.syswrite("listen '#{listener}', :tcp_nopush => true\n")
+
+ assert_raises(ArgumentError) do
+ Unicorn::Configurator.new(:config_file => tmp.path).commit!(test_struct)
+ end
+ end
+
def test_after_fork_proc
test_struct = TestStruct.new
[ proc { |a,b| }, Proc.new { |a,b| }, lambda { |a,b| } ].each do |my_proc|
--
1.7.10.2 (Apple Git-33)
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 3%]
* Re: Combating nginx 499 HTTP responses during flash traffic scenario
2012-11-06 3:16 2% ` Tom Burns
@ 2012-11-06 21:23 0% ` Eric Wong
2012-11-29 15:52 3% ` Tom Burns
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2012-11-06 21:23 UTC (permalink / raw)
To: unicorn list
Tom Burns <tom.burns@jadedpixel.com> wrote:
> On Mon, Nov 5, 2012 at 6:48 AM, Eric Wong <normalperson@yhbt.net> wrote:
> > We can wait until you can report on how this change improves your
> > situation before fleshing this out. Real-world results are always
> > good to have :>
>
> Agreed.
>
> We're going to be testing this this week so I should have some results
> to share by the weekend. We only experience the problem during major
> sales so it may or may not manifest without our traffic generation
> tool.
Holidays are coming up, should be lots of traffic :)
> I'd like to be testing a patch close to the finished product so I've
> addressed all of your comments from the previous email (including the
> modification to the C extension) in the patch below.
Thanks for the updated patch. A few comments below, apologies for the
nitpicks :)
> > Random thought: HttpResponse generation gains even more coupling
> > with the current Http{Request,Parser} state. Organizing code is hard :x
> Agreed. Without a class wrapping the raw socket to hold state I
> didn't see a better way to accomplish this, but I've only been looking
> at this code for the past week or so.
I'm leaning towards just having one HttpState class which encompasses
the entire client state (request/response). I did that earlier this
year for a single-purpose (non-Ruby) HTTP daemon and that design makes
the most sense to me.
Maybe we'll modify unicorn around that sooner or later...
> diff --git a/ext/unicorn_http/unicorn_http.rl b/ext/unicorn_http/unicorn_http.rl
> index 96dcf83..52f7f3c 100644
> --- a/ext/unicorn_http/unicorn_http.rl
> +++ b/ext/unicorn_http/unicorn_http.rl
> @@ -115,7 +115,7 @@ struct http_parser {
> } len;
> };
>
> -static ID id_clear, id_set_backtrace;
> +static ID id_clear, id_set_backtrace, id_response_start_sent;
>
> static void finalize_header(struct http_parser *hp);
>
> @@ -626,6 +626,7 @@ static VALUE HttpParser_clear(VALUE self)
>
> http_parser_init(hp);
> rb_funcall(hp->env, id_clear, 0);
> + rb_funcall(self, id_response_start_sent, 1, Qfalse);
Nitpick: Since HttpParser is already an alias of the HttpRequest class,
rb_ivar_set() should be a hair faster as it won't have to go through
normal method lookup.
> return self;
> }
> @@ -1031,6 +1032,7 @@ void Init_unicorn_http(void)
> SET_GLOBAL(g_http_connection, "CONNECTION");
> id_clear = rb_intern("clear");
> id_set_backtrace = rb_intern("set_backtrace");
> + id_response_start_sent = rb_intern("response_start_sent=");
> init_unicorn_httpdate();
> }
> #undef SET_GLOBAL
> diff --git a/lib/unicorn/configurator.rb b/lib/unicorn/configurator.rb
> index 89cbf5c..5f329af 100644
> --- a/lib/unicorn/configurator.rb
> +++ b/lib/unicorn/configurator.rb
> @@ -45,6 +45,7 @@ class Unicorn::Configurator
> },
> :pid => nil,
> :preload_app => false,
> + :check_client_connection => false,
> :rewindable_input => true, # for Rack 2.x: (Rack::VERSION[0] <= 1),
> :client_body_buffer_size => Unicorn::Const::MAX_BODY,
> :trust_x_forwarded => true,
> @@ -96,6 +97,13 @@ class Unicorn::Configurator
> if ready_pipe = RACKUP.delete(:ready_pipe)
> server.ready_pipe = ready_pipe
> end
> + if set[:check_client_connection]
> + set[:listeners].each do |address|
> + if set[:listener_opts][address][:tcp_nopush] == true ||
> set[:listener_opts][address][:tcp_nodelay] == true
Oops, I missed long lines the first time. It looks like your MUA did
mangle the long line. Wrap everything at <80 columns should help avoid
the issue (regardless of MUA, my brain cannot process >80 columns well)
> + raise ArgumentError, "With check_client_connection set to
> true both :tcp_nopush and :tcp_nodelay listener options must be set to
> false."
Likewise, error messages should be more concise and easier to read
in smaller terminals.
Probably:
check_client_connection is incompatible with (tcp_nopush|tcp_nodelay):true
> @@ -454,6 +462,12 @@ class Unicorn::Configurator
> set_int(:client_body_buffer_size, bytes, 0)
> end
>
> + # When enabled, unicorn will check the client connection by writing
> + # the beginning of the HTTP headers before calling the application.
Good to document the :tcp_* listener option incompatibilities here, too.
> + def check_client_connection(bool)
> + set_bool(:check_client_connection, bool)
> + end
> +
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Combating nginx 499 HTTP responses during flash traffic scenario
@ 2012-11-06 3:16 2% ` Tom Burns
2012-11-06 21:23 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Tom Burns @ 2012-11-06 3:16 UTC (permalink / raw)
To: unicorn list
On Mon, Nov 5, 2012 at 6:48 AM, Eric Wong <normalperson@yhbt.net> wrote:
> We can wait until you can report on how this change improves your
> situation before fleshing this out. Real-world results are always
> good to have :>
Agreed.
We're going to be testing this this week so I should have some results
to share by the weekend. We only experience the problem during major
sales so it may or may not manifest without our traffic generation
tool.
I'd like to be testing a patch close to the finished product so I've
addressed all of your comments from the previous email (including the
modification to the C extension) in the patch below.
>
> Random thought: HttpResponse generation gains even more coupling
> with the current Http{Request,Parser} state. Organizing code is hard :x
Agreed. Without a class wrapping the raw socket to hold state I
didn't see a better way to accomplish this, but I've only been looking
at this code for the past week or so.
Cheers,
Tom
---
>From c696bc0cb4df223a096142b6f314c8c2d83255be Mon Sep 17 00:00:00 2001
From: Tom Burns <tom.burns@jadedpixel.com>
Date: Tue, 30 Oct 2012 16:22:21 -0400
Subject: [PATCH] Begin writing HTTP request headers early to detect
disconnected clients
This patch checks incoming connections and avoids calling the application
if the connection has been closed.
It works by sending the beginning of the HTTP response before calling
the application to see if the socket can successfully be written to.
By enabling this feature users can avoid wasting application rendering
time only to find the connection is closed when attempting to write, and
throwing out the result.
When a client disconnects while being queued or processed, Nginx will log
HTTP response 499 but the application will log a 200.
Enabling this feature will minimize the time window during which the problem
can arise.
The feature is disabled by default and can be enabled by adding
'check_client_connection true' to the unicorn config.
---
examples/unicorn.conf.rb | 6 ++++++
ext/unicorn_http/unicorn_http.rl | 4 +++-
lib/unicorn/configurator.rb | 14 ++++++++++++++
lib/unicorn/const.rb | 12 ++++++++----
lib/unicorn/http_request.rb | 19 +++++++++++++++++++
lib/unicorn/http_response.rb | 5 +++--
lib/unicorn/http_server.rb | 22 ++++++++++++++++++++--
test/exec/test_exec.rb | 7 ++++++-
test/unit/test_configurator.rb | 24 ++++++++++++++++++++++++
9 files changed, 103 insertions(+), 10 deletions(-)
diff --git a/examples/unicorn.conf.rb b/examples/unicorn.conf.rb
index 0238043..1f4c9c0 100644
--- a/examples/unicorn.conf.rb
+++ b/examples/unicorn.conf.rb
@@ -46,6 +46,12 @@ preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
GC.copy_on_write_friendly = true
+# Enable this flag to have unicorn test client connections by writing the
+# beginning of the HTTP headers before calling the application. This
+# prevents calling the application for connections that have disconnected
+# while queued.
+check_client_connection false
+
before_fork do |server, worker|
# the following is highly recomended for Rails + "preload_app true"
# as there's no need for the master process to hold a connection
diff --git a/ext/unicorn_http/unicorn_http.rl b/ext/unicorn_http/unicorn_http.rl
index 96dcf83..52f7f3c 100644
--- a/ext/unicorn_http/unicorn_http.rl
+++ b/ext/unicorn_http/unicorn_http.rl
@@ -115,7 +115,7 @@ struct http_parser {
} len;
};
-static ID id_clear, id_set_backtrace;
+static ID id_clear, id_set_backtrace, id_response_start_sent;
static void finalize_header(struct http_parser *hp);
@@ -626,6 +626,7 @@ static VALUE HttpParser_clear(VALUE self)
http_parser_init(hp);
rb_funcall(hp->env, id_clear, 0);
+ rb_funcall(self, id_response_start_sent, 1, Qfalse);
return self;
}
@@ -1031,6 +1032,7 @@ void Init_unicorn_http(void)
SET_GLOBAL(g_http_connection, "CONNECTION");
id_clear = rb_intern("clear");
id_set_backtrace = rb_intern("set_backtrace");
+ id_response_start_sent = rb_intern("response_start_sent=");
init_unicorn_httpdate();
}
#undef SET_GLOBAL
diff --git a/lib/unicorn/configurator.rb b/lib/unicorn/configurator.rb
index 89cbf5c..5f329af 100644
--- a/lib/unicorn/configurator.rb
+++ b/lib/unicorn/configurator.rb
@@ -45,6 +45,7 @@ class Unicorn::Configurator
},
:pid => nil,
:preload_app => false,
+ :check_client_connection => false,
:rewindable_input => true, # for Rack 2.x: (Rack::VERSION[0] <= 1),
:client_body_buffer_size => Unicorn::Const::MAX_BODY,
:trust_x_forwarded => true,
@@ -96,6 +97,13 @@ class Unicorn::Configurator
if ready_pipe = RACKUP.delete(:ready_pipe)
server.ready_pipe = ready_pipe
end
+ if set[:check_client_connection]
+ set[:listeners].each do |address|
+ if set[:listener_opts][address][:tcp_nopush] == true ||
set[:listener_opts][address][:tcp_nodelay] == true
+ raise ArgumentError, "With check_client_connection set to
true both :tcp_nopush and :tcp_nodelay listener options must be set to
false."
+ end
+ end
+ end
set.each do |key, value|
value == :unset and next
skip.include?(key) and next
@@ -454,6 +462,12 @@ class Unicorn::Configurator
set_int(:client_body_buffer_size, bytes, 0)
end
+ # When enabled, unicorn will check the client connection by writing
+ # the beginning of the HTTP headers before calling the application.
+ def check_client_connection(bool)
+ set_bool(:check_client_connection, bool)
+ end
+
# Allow redirecting $stderr to a given path. Unlike doing this from
# the shell, this allows the unicorn process to know the path its
# writing to and rotate the file if it is used for logging. The
diff --git a/lib/unicorn/const.rb b/lib/unicorn/const.rb
index b3d8d71..f0c4c12 100644
--- a/lib/unicorn/const.rb
+++ b/lib/unicorn/const.rb
@@ -29,12 +29,16 @@ module Unicorn::Const
# :stopdoc:
# common errors we'll send back
- ERROR_400_RESPONSE = "HTTP/1.1 400 Bad Request\r\n\r\n"
- ERROR_414_RESPONSE = "HTTP/1.1 414 Request-URI Too Long\r\n\r\n"
- ERROR_413_RESPONSE = "HTTP/1.1 413 Request Entity Too Large\r\n\r\n"
- ERROR_500_RESPONSE = "HTTP/1.1 500 Internal Server Error\r\n\r\n"
+ ERROR_400_RESPONSE = "400 Bad Request\r\n\r\n"
+ ERROR_414_RESPONSE = "414 Request-URI Too Long\r\n\r\n"
+ ERROR_413_RESPONSE = "413 Request Entity Too Large\r\n\r\n"
+ ERROR_500_RESPONSE = "500 Internal Server Error\r\n\r\n"
+
EXPECT_100_RESPONSE = "HTTP/1.1 100 Continue\r\n\r\n"
+ EXPECT_100_RESPONSE_SUFFIXED = "100 Continue\r\n\r\nHTTP/1.1 "
+ HTTP_RESPONSE_START = ['HTTP', '/1.1 ']
HTTP_EXPECT = "HTTP_EXPECT"
+
# :startdoc:
end
diff --git a/lib/unicorn/http_request.rb b/lib/unicorn/http_request.rb
index a0435d6..79ead2e 100644
--- a/lib/unicorn/http_request.rb
+++ b/lib/unicorn/http_request.rb
@@ -22,11 +22,14 @@ class Unicorn::HttpParser
NULL_IO = StringIO.new("")
+ attr_accessor :response_start_sent
+
# :stopdoc:
# A frozen format for this is about 15% faster
REMOTE_ADDR = 'REMOTE_ADDR'.freeze
RACK_INPUT = 'rack.input'.freeze
@@input_class = Unicorn::TeeInput
+ @@check_client_connection = false
def self.input_class
@@input_class
@@ -35,6 +38,15 @@ class Unicorn::HttpParser
def self.input_class=(klass)
@@input_class = klass
end
+
+ def self.check_client_connection
+ @@check_client_connection
+ end
+
+ def self.check_client_connection=(bool)
+ @@check_client_connection = bool
+ end
+
# :startdoc:
# Does the majority of the IO processing. It has been written in
@@ -70,6 +82,13 @@ class Unicorn::HttpParser
# an Exception thrown from the parser will throw us out of the loop
false until add_parse(socket.kgio_read!(16384))
end
+
+ # detect if the socket is valid by writing a partial response:
+ if @@check_client_connection && headers?
+ @response_start_sent = true
+ Unicorn::Const::HTTP_RESPONSE_START.each { |c| socket.write(c) }
+ end
+
e[RACK_INPUT] = 0 == content_length ?
NULL_IO : @@input_class.new(socket, self)
e.merge!(DEFAULTS)
diff --git a/lib/unicorn/http_response.rb b/lib/unicorn/http_response.rb
index b781e20..9c2bacc 100644
--- a/lib/unicorn/http_response.rb
+++ b/lib/unicorn/http_response.rb
@@ -18,11 +18,12 @@ module Unicorn::HttpResponse
CRLF = "\r\n"
# writes the rack_response to socket as an HTTP response
- def http_response_write(socket, status, headers, body)
+ def http_response_write(socket, status, headers, body,
response_start_sent=false)
status = CODES[status.to_i] || status
+ http_response_start = response_start_sent ? '' : 'HTTP/1.1 '
if headers
- buf = "HTTP/1.1 #{status}\r\n" \
+ buf = "#{http_response_start}#{status}\r\n" \
"Date: #{httpdate}\r\n" \
"Status: #{status}\r\n" \
"Connection: close\r\n"
diff --git a/lib/unicorn/http_server.rb b/lib/unicorn/http_server.rb
index 13df55a..8729830 100644
--- a/lib/unicorn/http_server.rb
+++ b/lib/unicorn/http_server.rb
@@ -17,6 +17,7 @@ class Unicorn::HttpServer
:listener_opts, :preload_app,
:reexec_pid, :orig_app, :init_listeners,
:master_pid, :config, :ready_pipe, :user
+
attr_reader :pid, :logger
include Unicorn::SocketHelper
include Unicorn::HttpResponse
@@ -355,6 +356,14 @@ class Unicorn::HttpServer
Unicorn::HttpParser.trust_x_forwarded = bool
end
+ def check_client_connection
+ Unicorn::HttpRequest.check_client_connection
+ end
+
+ def check_client_connection=(bool)
+ Unicorn::HttpRequest.check_client_connection = bool
+ end
+
private
# wait for a signal hander to wake us up and then consume the pipe
@@ -524,23 +533,32 @@ class Unicorn::HttpServer
Unicorn.log_error(@logger, "app error", e)
Unicorn::Const::ERROR_500_RESPONSE
end
+ msg = "HTTP/1.1 #{msg}" unless @request.response_start_sent
client.kgio_trywrite(msg)
client.close
rescue
end
+ def expect_100_response
+ if @request.response_start_sent
+ Unicorn::Const::EXPECT_100_RESPONSE_SUFFIXED
+ else
+ Unicorn::Const::EXPECT_100_RESPONSE
+ end
+ end
+
# once a client is accepted, it is processed in its entirety here
# in 3 easy steps: read request, call app, write app response
def process_client(client)
status, headers, body = @app.call(env = @request.read(client))
if 100 == status.to_i
- client.write(Unicorn::Const::EXPECT_100_RESPONSE)
+ client.write(expect_100_response)
env.delete(Unicorn::Const::HTTP_EXPECT)
status, headers, body = @app.call(env)
end
@request.headers? or headers = nil
- http_response_write(client, status, headers, body)
+ http_response_write(client, status, headers, body,
@request.response_start_sent)
client.shutdown # in case of fork() in Rack app
client.close # flush and uncork socket immediately, no keepalive
rescue => e
diff --git a/test/exec/test_exec.rb b/test/exec/test_exec.rb
index b30a3d6..1cee2b7 100644
--- a/test/exec/test_exec.rb
+++ b/test/exec/test_exec.rb
@@ -871,13 +871,14 @@ EOF
wait_for_death(pid)
end
- def hup_test_common(preload)
+ def hup_test_common(preload, check_client=false)
File.open("config.ru", "wb") { |fp| fp.syswrite(HI.gsub("HI", '#$$')) }
pid_file = Tempfile.new('pid')
ucfg = Tempfile.new('unicorn_test_config')
ucfg.syswrite("listen '#@addr:#@port'\n")
ucfg.syswrite("pid '#{pid_file.path}'\n")
ucfg.syswrite("preload_app true\n") if preload
+ ucfg.syswrite("check_client_connection true\n") if check_client
ucfg.syswrite("stderr_path 'test_stderr.#$$.log'\n")
ucfg.syswrite("stdout_path 'test_stdout.#$$.log'\n")
pid = xfork {
@@ -942,6 +943,10 @@ EOF
hup_test_common(false)
end
+ def test_check_client_hup
+ hup_test_common(false, true)
+ end
+
def test_default_listen_hup_holds_listener
default_listen_lock do
res, pid_path = default_listen_setup
diff --git a/test/unit/test_configurator.rb b/test/unit/test_configurator.rb
index c19c427..b9c22d7 100644
--- a/test/unit/test_configurator.rb
+++ b/test/unit/test_configurator.rb
@@ -139,6 +139,30 @@ class TestConfigurator < Test::Unit::TestCase
end
end
+ def test_check_client_connection
+ tmp = Tempfile.new('unicorn_config')
+ test_struct = TestStruct.new
+ tmp.syswrite("check_client_connection true\n")
+
+ assert_nothing_raised do
+ Unicorn::Configurator.new(:config_file => tmp.path).commit!(test_struct)
+ end
+
+ assert test_struct.check_client_connection
+ end
+
+ def test_check_client_connection_with_tcp_bad
+ tmp = Tempfile.new('unicorn_config')
+ test_struct = TestStruct.new
+ listener = "127.0.0.1:12345"
+ tmp.syswrite("check_client_connection true\n")
+ tmp.syswrite("listen '#{listener}', :tcp_nopush => true\n")
+
+ assert_raises(ArgumentError) do
+ Unicorn::Configurator.new(:config_file => tmp.path).commit!(test_struct)
+ end
+ end
+
def test_after_fork_proc
test_struct = TestStruct.new
[ proc { |a,b| }, Proc.new { |a,b| }, lambda { |a,b| } ].each do |my_proc|
--
1.7.7.5 (Apple Git-26)
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 2%]
* Re: Combating nginx 499 HTTP responses during flash traffic scenario
@ 2012-11-03 22:45 2% ` Tom Burns
0 siblings, 1 reply; 200+ results
From: Tom Burns @ 2012-11-03 22:45 UTC (permalink / raw)
To: unicorn list
On Fri, Nov 2, 2012 at 3:38 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Everything looks good for stock configurations. The ERROR_XXX_RESPONSE
> constants should have "HTTP/1.1 " removed if used with this option, too.
> That requires keeping track of whether or not we've written out
> "HTTP/1.1 ", yet.
The patch below tracks if we've sent the start of the response. It
also passes that to http_response_write as a parameter with default
value false. By doing this, the test suite passes if you change the
default value for check_client_connection to true, which makes me feel
a lot better about the patch.
> > The only thing it's missing from your TODO is enforcing
> > tcp_nodelay/tcp_nopush as I wasn't sure where was the best place to do
> > the enforcement.
>
> It should probably be done inside Unicorn::Configurator#commit!
So, I still didn't so this, because in commit! we don't know if it's a
TCP or UNIX socket, and I don't think it'd be nice to force tcp
configs if the user's using a UNIX socket. If you disagree I can add
the check there, it just seemed weird when I looked at it.
>
> You'll probably find it more reliable and easier to use "git send-email".
Sadly with 2-factor authentication I think this is a no go.
Let me know what you think!
Cheers,
Tom
>From d7e249202b0fd5c24f2b98c700e02bf992c6576b Mon Sep 17 00:00:00 2001
From: Tom Burns <tom.burns@jadedpixel.com>
Date: Tue, 30 Oct 2012 16:22:21 -0400
Subject: [PATCH] Begin writing HTTP request headers early to detect
disconnected clients
---
examples/unicorn.conf.rb | 6 ++++++
lib/unicorn/configurator.rb | 7 +++++++
lib/unicorn/const.rb | 12 ++++++++----
lib/unicorn/http_request.rb | 21 +++++++++++++++++++++
lib/unicorn/http_response.rb | 5 +++--
lib/unicorn/http_server.rb | 23 +++++++++++++++++++++--
test/exec/test_exec.rb | 7 ++++++-
test/unit/test_configurator.rb | 12 ++++++++++++
8 files changed, 84 insertions(+), 9 deletions(-)
diff --git a/examples/unicorn.conf.rb b/examples/unicorn.conf.rb
index 0238043..1f4c9c0 100644
--- a/examples/unicorn.conf.rb
+++ b/examples/unicorn.conf.rb
@@ -46,6 +46,12 @@ preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
GC.copy_on_write_friendly = true
+# Enable this flag to have unicorn test client connections by writing the
+# beginning of the HTTP headers before calling the application. This
+# prevents calling the application for connections that have disconnected
+# while queued.
+check_client_connection false
+
before_fork do |server, worker|
# the following is highly recomended for Rails + "preload_app true"
# as there's no need for the master process to hold a connection
diff --git a/lib/unicorn/configurator.rb b/lib/unicorn/configurator.rb
index 89cbf5c..ca84a88 100644
--- a/lib/unicorn/configurator.rb
+++ b/lib/unicorn/configurator.rb
@@ -45,6 +45,7 @@ class Unicorn::Configurator
},
:pid => nil,
:preload_app => false,
+ :check_client_connection => false,
:rewindable_input => true, # for Rack 2.x: (Rack::VERSION[0] <= 1),
:client_body_buffer_size => Unicorn::Const::MAX_BODY,
:trust_x_forwarded => true,
@@ -454,6 +455,12 @@ class Unicorn::Configurator
set_int(:client_body_buffer_size, bytes, 0)
end
+ # When enabled, unicorn will check the client connection by writing
+ # the beginning of the HTTP headers before calling the application.
+ def check_client_connection(bool)
+ set_bool(:check_client_connection, bool)
+ end
+
# Allow redirecting $stderr to a given path. Unlike doing this from
# the shell, this allows the unicorn process to know the path its
# writing to and rotate the file if it is used for logging. The
diff --git a/lib/unicorn/const.rb b/lib/unicorn/const.rb
index b3d8d71..f0c4c12 100644
--- a/lib/unicorn/const.rb
+++ b/lib/unicorn/const.rb
@@ -29,12 +29,16 @@ module Unicorn::Const
# :stopdoc:
# common errors we'll send back
- ERROR_400_RESPONSE = "HTTP/1.1 400 Bad Request\r\n\r\n"
- ERROR_414_RESPONSE = "HTTP/1.1 414 Request-URI Too Long\r\n\r\n"
- ERROR_413_RESPONSE = "HTTP/1.1 413 Request Entity Too Large\r\n\r\n"
- ERROR_500_RESPONSE = "HTTP/1.1 500 Internal Server Error\r\n\r\n"
+ ERROR_400_RESPONSE = "400 Bad Request\r\n\r\n"
+ ERROR_414_RESPONSE = "414 Request-URI Too Long\r\n\r\n"
+ ERROR_413_RESPONSE = "413 Request Entity Too Large\r\n\r\n"
+ ERROR_500_RESPONSE = "500 Internal Server Error\r\n\r\n"
+
EXPECT_100_RESPONSE = "HTTP/1.1 100 Continue\r\n\r\n"
+ EXPECT_100_RESPONSE_SUFFIXED = "100 Continue\r\n\r\nHTTP/1.1 "
+ HTTP_RESPONSE_START = ['HTTP', '/1.1 ']
HTTP_EXPECT = "HTTP_EXPECT"
+
# :startdoc:
end
diff --git a/lib/unicorn/http_request.rb b/lib/unicorn/http_request.rb
index a0435d6..9aceb0e 100644
--- a/lib/unicorn/http_request.rb
+++ b/lib/unicorn/http_request.rb
@@ -22,11 +22,14 @@ class Unicorn::HttpParser
NULL_IO = StringIO.new("")
+ attr_accessor :response_start_sent
+
# :stopdoc:
# A frozen format for this is about 15% faster
REMOTE_ADDR = 'REMOTE_ADDR'.freeze
RACK_INPUT = 'rack.input'.freeze
@@input_class = Unicorn::TeeInput
+ @@check_client_connection = false
def self.input_class
@@input_class
@@ -35,6 +38,15 @@ class Unicorn::HttpParser
def self.input_class=(klass)
@@input_class = klass
end
+
+ def self.check_client_connection
+ @@check_client_connection
+ end
+
+ def self.check_client_connection=(bool)
+ @@check_client_connection = bool
+ end
+
# :startdoc:
# Does the majority of the IO processing. It has been written in
@@ -70,6 +82,15 @@ class Unicorn::HttpParser
# an Exception thrown from the parser will throw us out of the loop
false until add_parse(socket.kgio_read!(16384))
end
+
+ # detect if the socket is valid by writing a partial response:
+ if @@check_client_connection && headers?
+ @response_start_sent = true
+ Unicorn::Const::HTTP_RESPONSE_START.each { |c| socket.write(c) }
+ else
+ @response_start_sent = false
+ end
+
e[RACK_INPUT] = 0 == content_length ?
NULL_IO : @@input_class.new(socket, self)
e.merge!(DEFAULTS)
diff --git a/lib/unicorn/http_response.rb b/lib/unicorn/http_response.rb
index b781e20..9c2bacc 100644
--- a/lib/unicorn/http_response.rb
+++ b/lib/unicorn/http_response.rb
@@ -18,11 +18,12 @@ module Unicorn::HttpResponse
CRLF = "\r\n"
# writes the rack_response to socket as an HTTP response
- def http_response_write(socket, status, headers, body)
+ def http_response_write(socket, status, headers, body,
response_start_sent=false)
status = CODES[status.to_i] || status
+ http_response_start = response_start_sent ? '' : 'HTTP/1.1 '
if headers
- buf = "HTTP/1.1 #{status}\r\n" \
+ buf = "#{http_response_start}#{status}\r\n" \
"Date: #{httpdate}\r\n" \
"Status: #{status}\r\n" \
"Connection: close\r\n"
diff --git a/lib/unicorn/http_server.rb b/lib/unicorn/http_server.rb
index 13df55a..abe27db 100644
--- a/lib/unicorn/http_server.rb
+++ b/lib/unicorn/http_server.rb
@@ -17,6 +17,7 @@ class Unicorn::HttpServer
:listener_opts, :preload_app,
:reexec_pid, :orig_app, :init_listeners,
:master_pid, :config, :ready_pipe, :user
+
attr_reader :pid, :logger
include Unicorn::SocketHelper
include Unicorn::HttpResponse
@@ -355,6 +356,14 @@ class Unicorn::HttpServer
Unicorn::HttpParser.trust_x_forwarded = bool
end
+ def check_client_connection
+ Unicorn::HttpRequest.check_client_connection
+ end
+
+ def check_client_connection=(bool)
+ Unicorn::HttpRequest.check_client_connection = bool
+ end
+
private
# wait for a signal hander to wake us up and then consume the pipe
@@ -524,23 +533,33 @@ class Unicorn::HttpServer
Unicorn.log_error(@logger, "app error", e)
Unicorn::Const::ERROR_500_RESPONSE
end
+ msg = 'HTTP/1.1 ' + msg unless @request.response_start_sent
client.kgio_trywrite(msg)
client.close
rescue
end
+ def expect_100_response
+ if @request.response_start_sent
+ Unicorn::Const::EXPECT_100_RESPONSE_SUFFIXED
+ else
+ Unicorn::Const::EXPECT_100_RESPONSE
+ end
+ end
+
# once a client is accepted, it is processed in its entirety here
# in 3 easy steps: read request, call app, write app response
def process_client(client)
+ @request.response_start_sent = false
status, headers, body = @app.call(env = @request.read(client))
if 100 == status.to_i
- client.write(Unicorn::Const::EXPECT_100_RESPONSE)
+ client.write(expect_100_response)
env.delete(Unicorn::Const::HTTP_EXPECT)
status, headers, body = @app.call(env)
end
@request.headers? or headers = nil
- http_response_write(client, status, headers, body)
+ http_response_write(client, status, headers, body,
@request.response_start_sent)
client.shutdown # in case of fork() in Rack app
client.close # flush and uncork socket immediately, no keepalive
rescue => e
diff --git a/test/exec/test_exec.rb b/test/exec/test_exec.rb
index b30a3d6..1cee2b7 100644
--- a/test/exec/test_exec.rb
+++ b/test/exec/test_exec.rb
@@ -871,13 +871,14 @@ EOF
wait_for_death(pid)
end
- def hup_test_common(preload)
+ def hup_test_common(preload, check_client=false)
File.open("config.ru", "wb") { |fp| fp.syswrite(HI.gsub("HI", '#$$')) }
pid_file = Tempfile.new('pid')
ucfg = Tempfile.new('unicorn_test_config')
ucfg.syswrite("listen '#@addr:#@port'\n")
ucfg.syswrite("pid '#{pid_file.path}'\n")
ucfg.syswrite("preload_app true\n") if preload
+ ucfg.syswrite("check_client_connection true\n") if check_client
ucfg.syswrite("stderr_path 'test_stderr.#$$.log'\n")
ucfg.syswrite("stdout_path 'test_stdout.#$$.log'\n")
pid = xfork {
@@ -942,6 +943,10 @@ EOF
hup_test_common(false)
end
+ def test_check_client_hup
+ hup_test_common(false, true)
+ end
+
def test_default_listen_hup_holds_listener
default_listen_lock do
res, pid_path = default_listen_setup
diff --git a/test/unit/test_configurator.rb b/test/unit/test_configurator.rb
index c19c427..fc4170e 100644
--- a/test/unit/test_configurator.rb
+++ b/test/unit/test_configurator.rb
@@ -139,6 +139,18 @@ class TestConfigurator < Test::Unit::TestCase
end
end
+ def test_check_client_connection
+ tmp = Tempfile.new('unicorn_config')
+ test_struct = TestStruct.new
+ tmp.syswrite("check_client_connection true\n")
+
+ assert_nothing_raised do
+ Unicorn::Configurator.new(:config_file => tmp.path).commit!(test_struct)
+ end
+
+ assert test_struct.check_client_connection
+ end
+
def test_after_fork_proc
test_struct = TestStruct.new
[ proc { |a,b| }, Proc.new { |a,b| }, lambda { |a,b| } ].each do |my_proc|
--
1.7.7.5 (Apple Git-26)
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 2%]
* Re: Combating nginx 499 HTTP responses during flash traffic scenario
@ 2012-11-02 17:59 2% ` Tom Burns
0 siblings, 1 reply; 200+ results
From: Tom Burns @ 2012-11-02 17:59 UTC (permalink / raw)
To: unicorn list
On Tue, Oct 30, 2012 at 5:37 PM, Eric Wong <normalperson@yhbt.net> wrote:
>
> Tom Burns <tom.burns@jadedpixel.com> wrote:
> > We'd prefer to not have to fork unicorn for this change. How do you
> > feel about merging this or a derivative thereof? I can develop this
> > further if you can send me what you'd want.
>
> Sure thing!
Below is a patch for this functionality.
We're going to be testing this further next week before rolling it out
in production.
It's still pre-writing the entire HTTP/1.1 header start, but as just
two strings. It could be shortened to just pre-writing HT but I
thought writing that full word looked cleaner.
Please let me know what you think.
The only thing it's missing from your TODO is enforcing
tcp_nodelay/tcp_nopush as I wasn't sure where was the best place to do
the enforcement.
Never done this inline with GMail, sorry in advance if formatting gets
destroyed :)
Cheers,
Tom
---
examples/unicorn.conf.rb | 6 ++++++
lib/unicorn/configurator.rb | 7 +++++++
lib/unicorn/const.rb | 4 ++++
lib/unicorn/http_request.rb | 16 ++++++++++++++++
lib/unicorn/http_response.rb | 6 +++++-
lib/unicorn/http_server.rb | 19 ++++++++++++++++++-
test/exec/test_exec.rb | 7 ++++++-
test/unit/test_configurator.rb | 12 ++++++++++++
8 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/examples/unicorn.conf.rb b/examples/unicorn.conf.rb
index 0238043..1f4c9c0 100644
--- a/examples/unicorn.conf.rb
+++ b/examples/unicorn.conf.rb
@@ -46,6 +46,12 @@ preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
GC.copy_on_write_friendly = true
+# Enable this flag to have unicorn test client connections by writing the
+# beginning of the HTTP headers before calling the application. This
+# prevents calling the application for connections that have disconnected
+# while queued.
+check_client_connection false
+
before_fork do |server, worker|
# the following is highly recomended for Rails + "preload_app true"
# as there's no need for the master process to hold a connection
diff --git a/lib/unicorn/configurator.rb b/lib/unicorn/configurator.rb
index 89cbf5c..ca84a88 100644
--- a/lib/unicorn/configurator.rb
+++ b/lib/unicorn/configurator.rb
@@ -45,6 +45,7 @@ class Unicorn::Configurator
},
:pid => nil,
:preload_app => false,
+ :check_client_connection => false,
:rewindable_input => true, # for Rack 2.x: (Rack::VERSION[0] <= 1),
:client_body_buffer_size => Unicorn::Const::MAX_BODY,
:trust_x_forwarded => true,
@@ -454,6 +455,12 @@ class Unicorn::Configurator
set_int(:client_body_buffer_size, bytes, 0)
end
+ # When enabled, unicorn will check the client connection by writing
+ # the beginning of the HTTP headers before calling the application.
+ def check_client_connection(bool)
+ set_bool(:check_client_connection, bool)
+ end
+
# Allow redirecting $stderr to a given path. Unlike doing this from
# the shell, this allows the unicorn process to know the path its
# writing to and rotate the file if it is used for logging. The
diff --git a/lib/unicorn/const.rb b/lib/unicorn/const.rb
index b3d8d71..56598d9 100644
--- a/lib/unicorn/const.rb
+++ b/lib/unicorn/const.rb
@@ -33,8 +33,12 @@ module Unicorn::Const
ERROR_414_RESPONSE = "HTTP/1.1 414 Request-URI Too Long\r\n\r\n"
ERROR_413_RESPONSE = "HTTP/1.1 413 Request Entity Too Large\r\n\r\n"
ERROR_500_RESPONSE = "HTTP/1.1 500 Internal Server Error\r\n\r\n"
+
EXPECT_100_RESPONSE = "HTTP/1.1 100 Continue\r\n\r\n"
+ EXPECT_100_RESPONSE_SUFFIXED = "100 Continue\r\n\r\nHTTP/1.1 "
+ HTTP_RESPONSE_START = ['HTTP', '/1.1 ']
HTTP_EXPECT = "HTTP_EXPECT"
+
# :startdoc:
end
diff --git a/lib/unicorn/http_request.rb b/lib/unicorn/http_request.rb
index a0435d6..095ca7c 100644
--- a/lib/unicorn/http_request.rb
+++ b/lib/unicorn/http_request.rb
@@ -27,6 +27,7 @@ class Unicorn::HttpParser
REMOTE_ADDR = 'REMOTE_ADDR'.freeze
RACK_INPUT = 'rack.input'.freeze
@@input_class = Unicorn::TeeInput
+ @@check_client_connection = false
def self.input_class
@@input_class
@@ -35,6 +36,15 @@ class Unicorn::HttpParser
def self.input_class=(klass)
@@input_class = klass
end
+
+ def self.check_client_connection
+ @@check_client_connection
+ end
+
+ def self.check_client_connection=(bool)
+ @@check_client_connection = bool
+ end
+
# :startdoc:
# Does the majority of the IO processing. It has been written in
@@ -70,6 +80,12 @@ class Unicorn::HttpParser
# an Exception thrown from the parser will throw us out of the loop
false until add_parse(socket.kgio_read!(16384))
end
+
+ # detect if the socket is valid by writing a partial response:
+ if @@check_client_connection && headers?
+ Unicorn::Const::HTTP_RESPONSE_START.each { |c| socket.write(c) }
+ end
+
e[RACK_INPUT] = 0 == content_length ?
NULL_IO : @@input_class.new(socket, self)
e.merge!(DEFAULTS)
diff --git a/lib/unicorn/http_response.rb b/lib/unicorn/http_response.rb
index b781e20..10a92d1 100644
--- a/lib/unicorn/http_response.rb
+++ b/lib/unicorn/http_response.rb
@@ -17,12 +17,16 @@ module Unicorn::HttpResponse
}
CRLF = "\r\n"
+ def http_response_start
+ Unicorn::HttpParser.check_client_connection ? '' : 'HTTP/1.1 '
+ end
+
# writes the rack_response to socket as an HTTP response
def http_response_write(socket, status, headers, body)
status = CODES[status.to_i] || status
if headers
- buf = "HTTP/1.1 #{status}\r\n" \
+ buf = "#{http_response_start}#{status}\r\n" \
"Date: #{httpdate}\r\n" \
"Status: #{status}\r\n" \
"Connection: close\r\n"
diff --git a/lib/unicorn/http_server.rb b/lib/unicorn/http_server.rb
index 13df55a..3e061af 100644
--- a/lib/unicorn/http_server.rb
+++ b/lib/unicorn/http_server.rb
@@ -17,6 +17,7 @@ class Unicorn::HttpServer
:listener_opts, :preload_app,
:reexec_pid, :orig_app, :init_listeners,
:master_pid, :config, :ready_pipe, :user
+
attr_reader :pid, :logger
include Unicorn::SocketHelper
include Unicorn::HttpResponse
@@ -355,6 +356,14 @@ class Unicorn::HttpServer
Unicorn::HttpParser.trust_x_forwarded = bool
end
+ def check_client_connection
+ Unicorn::HttpRequest.check_client_connection
+ end
+
+ def check_client_connection=(bool)
+ Unicorn::HttpRequest.check_client_connection = bool
+ end
+
private
# wait for a signal hander to wake us up and then consume the pipe
@@ -529,13 +538,21 @@ class Unicorn::HttpServer
rescue
end
+ def expect_100_response
+ if Unicorn::HttpRequest.check_client_connection
+ Unicorn::Const::EXPECT_100_RESPONSE_SUFFIXED
+ else
+ Unicorn::Const::EXPECT_100_RESPONSE
+ end
+ end
+
# once a client is accepted, it is processed in its entirety here
# in 3 easy steps: read request, call app, write app response
def process_client(client)
status, headers, body = @app.call(env = @request.read(client))
if 100 == status.to_i
- client.write(Unicorn::Const::EXPECT_100_RESPONSE)
+ client.write(expect_100_response)
env.delete(Unicorn::Const::HTTP_EXPECT)
status, headers, body = @app.call(env)
end
diff --git a/test/exec/test_exec.rb b/test/exec/test_exec.rb
index b30a3d6..1cee2b7 100644
--- a/test/exec/test_exec.rb
+++ b/test/exec/test_exec.rb
@@ -871,13 +871,14 @@ EOF
wait_for_death(pid)
end
- def hup_test_common(preload)
+ def hup_test_common(preload, check_client=false)
File.open("config.ru", "wb") { |fp| fp.syswrite(HI.gsub("HI", '#$$')) }
pid_file = Tempfile.new('pid')
ucfg = Tempfile.new('unicorn_test_config')
ucfg.syswrite("listen '#@addr:#@port'\n")
ucfg.syswrite("pid '#{pid_file.path}'\n")
ucfg.syswrite("preload_app true\n") if preload
+ ucfg.syswrite("check_client_connection true\n") if check_client
ucfg.syswrite("stderr_path 'test_stderr.#$$.log'\n")
ucfg.syswrite("stdout_path 'test_stdout.#$$.log'\n")
pid = xfork {
@@ -942,6 +943,10 @@ EOF
hup_test_common(false)
end
+ def test_check_client_hup
+ hup_test_common(false, true)
+ end
+
def test_default_listen_hup_holds_listener
default_listen_lock do
res, pid_path = default_listen_setup
diff --git a/test/unit/test_configurator.rb b/test/unit/test_configurator.rb
index c19c427..fc4170e 100644
--- a/test/unit/test_configurator.rb
+++ b/test/unit/test_configurator.rb
@@ -139,6 +139,18 @@ class TestConfigurator < Test::Unit::TestCase
end
end
+ def test_check_client_connection
+ tmp = Tempfile.new('unicorn_config')
+ test_struct = TestStruct.new
+ tmp.syswrite("check_client_connection true\n")
+
+ assert_nothing_raised do
+ Unicorn::Configurator.new(:config_file => tmp.path).commit!(test_struct)
+ end
+
+ assert test_struct.check_client_connection
+ end
+
def test_after_fork_proc
test_struct = TestStruct.new
[ proc { |a,b| }, Proc.new { |a,b| }, lambda { |a,b| } ].each do |my_proc|
--
1.7.7.5 (Apple Git-26)
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 2%]
* Re: [PATCH] explicitly use escaped minus in man pages
@ 2012-10-18 8:04 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2012-10-18 8:04 UTC (permalink / raw)
To: unicorn list
Hleb Valoshka <375gnu@gmail.com> wrote:
> On 10/15/12, Eric Wong <normalperson@yhbt.net> wrote:
> > All the manpages are generated with pandoc. Can you send a patch
> > for the Markdown files in Documentation/*.1.txt instead? Thanks
> > in advance.
>
> I'll try but I'm not sure that it's possible, it seems to be only
> groff-specific issue to treat minus as hyphen.
>
> May be it's better to try to patch pandoc.
Yes, it is probably a bug in pandoc.
Btw, I'm not married to pandoc, either. I'm open to migrating to ronn
(or similar) if somebody is willing to try it out. ronn might be an
easier tool for Rubyists on various platforms to install, too, and I
likely would've chosen it if I had known about it back in the day...
> > I generate manpages using pandoc 1.5.1.1-5+b1 from Debian stable
> > using: make -C Documentation
>
> I'll try it with pandoc 1.9.4.2-2 from sid, maybe it knows groff
> better than 1.5 :)
I have the same version on my wheezy machine, and it doesn't seem
to escape hyphens, either.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: [PATCH] chowning /dev/null should be guarded against
@ 2012-10-02 4:25 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2012-10-02 4:25 UTC (permalink / raw)
To: unicorn list; +Cc: Joel Meador
Joel Meador <joel@expectedbehavior.com> wrote:
> Eric Wong wrote:
> >--- a/lib/unicorn/util.rb
> >+++ b/lib/unicorn/util.rb
> >@@ -7,6 +7,7 @@ def self.is_log?(fp)
> > append_flags = File::WRONLY | File::APPEND
> >
> > ! fp.closed?&&
> >+ fp.stat.file?&&
> > fp.sync&&
> > (fp.fcntl(Fcntl::F_GETFL)& append_flags) == append_flags
> > rescue IOError, Errno::EBADF
> This looks much better as a general solution to the problem. +1
> Thanks, Eric!
Thanks for reporting! Pushed to "master" of git://bogomips.org/unicorn
as commit 032791b9a367f67febbe7534f6ea4cac127e7897
Will probably tag + release a new version in day or two.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: SIGUSR2 from symlinked working directory
[not found] ` <7FF46C3E-8491-43D8-8617-9D628C4A85C7@gmail.com>
@ 2012-08-07 8:58 3% ` Danial Pearce
0 siblings, 0 replies; 200+ results
From: Danial Pearce @ 2012-08-07 8:58 UTC (permalink / raw)
To: unicorn list
> I ran into the same issue. Resetting BUNDLE_GEMFILE (so it wasn't
> dereference to the ephemeral release path) in the before_exec hook worked
> for me. See http://unicorn.bogomips.org/Sandbox.html
Thanks Aaron. Just stumbled up that myself and was exactly what I needed.
About to find out of resetting BUNDLE_GEMFILE is all I need to do. Did
you need to override the Unicorn::HttpServer::START_CTX[0] as per the
top of that page? It makes sense that I'd need to, I will find out I
guess. Although, if it is required, I dunno how I will go about
finding the path without hard coding the unicorn version number or
using --binstubs on bundler.
regards,
Danial
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* [RFC/PATCH] remove Rails-oriented integration tests
@ 2012-07-28 2:22 6% Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2012-07-28 2:22 UTC (permalink / raw)
To: mongrel-unicorn
(This is a large patch which deletes a lot of files, so it's pointless
to post in its entirety here. Full diffstat and --diff-filter=M
output below. I've pushed this to the "pu" branch of
git://bogomips.org/unicorn.git
commit 91a3cde091d4ae6ff436681f155b3907daae1c04)
It's too much overhead to keep Rails-specific tests working,
especially when it's hauling in an ancient version of SQLite3.
Since Rails 3 has settled down with Rack and unicorn_rails is
unlikely to need changing in the future, we can drop these
tests.
---
GNUmakefile | 31 +--
script/isolate_for_tests | 18 --
Summary of full diffstat:
94 files changed, 2 insertions(+), 1598 deletions(-)
diff --git a/GNUmakefile b/GNUmakefile
index 61fb739..ea13486 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -32,16 +32,13 @@ MYLIBS = $(RUBYLIB):$(ISOLATE_LIBS)
# dunno how to implement this as concisely in Ruby, and hell, I love awk
awk_slow := awk '/def test_/{print FILENAME"--"$$2".n"}' 2>/dev/null
-rails_vers := $(subst test/rails/app-,,$(wildcard test/rails/app-*))
slow_tests := test/unit/test_server.rb test/exec/test_exec.rb \
test/unit/test_signals.rb test/unit/test_upload.rb
log_suffix = .$(RUBY_ENGINE).$(RUBY_VERSION).log
-T_r := $(wildcard test/rails/test*.rb)
-T := $(filter-out $(slow_tests) $(T_r), $(wildcard test/*/test*.rb))
+T := $(filter-out $(slow_tests), $(wildcard test/*/test*.rb))
T_n := $(shell $(awk_slow) $(slow_tests))
T_log := $(subst .rb,$(log_suffix),$(T))
T_n_log := $(subst .n,$(log_suffix),$(T_n))
-T_r_log := $(subst .r,$(log_suffix),$(T_r))
test_prefix = $(CURDIR)/test/$(RUBY_ENGINE)-$(RUBY_VERSION)
ext := ext/unicorn_http
@@ -93,7 +90,7 @@ $(slow_tests): $(test_prefix)/.stamp
test-integration: $(test_prefix)/.stamp
$(MAKE) -C t
-test-all: test test-rails test-integration
+test-all: test test-integration
TEST_OPTS = -v
check_test = grep '0 failures, 0 errors' $(t) >/dev/null
@@ -199,30 +196,6 @@ doc_gz:
for i in $(docs); do \
gzip --rsyncable -9 < $$i > $$i.gz; touch -r $$i $$i.gz; done
-rails_git_url = git://github.com/rails/rails.git
-rails_git := vendor/rails.git
-$(rails_git)/info/cloned-stamp:
- git clone --mirror -q $(rails_git_url) $(rails_git)
- > $@
-
-$(rails_git)/info/v2.2.3-stamp: $(rails_git)/info/cloned-stamp
- cd $(rails_git) && git fetch
- cd $(rails_git) && git rev-parse --verify refs/tags/v2.2.3
- > $@
-
-rails_tests := $(addsuffix .r,$(addprefix $(T_r).,$(rails_vers)))
-test-rails: $(rails_tests)
-$(T_r).%.r: t = $(addsuffix $(log_suffix),$@)
-$(T_r).%.r: rv = $(subst .r,,$(subst $(T_r).,,$@))
-$(T_r).%.r: extra = ' 'v$(rv)
-$(T_r).%.r: arg = $(T_r)
-$(T_r).%.r: export PATH := $(test_prefix)/bin:$(PATH)
-$(T_r).%.r: export RUBYLIB := $(test_prefix):$(test_prefix)/lib:$(MYLIBS)
-$(T_r).%.r: export UNICORN_RAILS_TEST_VERSION = $(rv)
-$(T_r).%.r: export RAILS_GIT_REPO = $(CURDIR)/$(rails_git)
-$(T_r).%.r: $(test_prefix)/.stamp $(rails_git)/info/v2.2.3-stamp
- $(run_test)
-
ifneq ($(VERSION),)
rfproject := mongrel
rfpackage := unicorn
diff --git a/script/isolate_for_tests b/script/isolate_for_tests
index 5e6139c..00a3f2b 100755
--- a/script/isolate_for_tests
+++ b/script/isolate_for_tests
@@ -16,9 +16,6 @@ opts = {
pid = fork do
Isolate.now!(opts) do
- if RUBY_VERSION.to_f < 2.0
- gem 'sqlite3-ruby', '1.2.5'
- end
gem 'raindrops', '0.8.0'
gem 'kgio-monkey', '0.4.0'
gem 'kgio', '2.7.4'
@@ -33,18 +30,3 @@ File.open("#{dst}.#$$", "w") do |fp|
fp.puts "ISOLATE_LIBS=#{lib_paths.join(':')}"
end
File.rename("#{dst}.#$$", dst)
-
-# pure Ruby gems can be shared across all Rubies
-%w(3.0.0).each do |rails_ver|
- opts[:path] = "tmp/isolate/rails-#{rails_ver}"
- pid = fork do
- Isolate.now!(opts) do
- gem 'rake', '0.8.7'
- gem 'rails', rails_ver
- end
- end
- _, status = Process.waitpid2(pid)
- status.success? or abort status.inspect
- more = Dir["#{opts[:path]}/gems/*-*/lib"].map { |x| File.expand_path(x) }
- lib_paths.concat(more)
-end
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 6%]
* Re: Detecting unicorn / defining after_fork after master startup
@ 2012-07-22 21:20 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2012-07-22 21:20 UTC (permalink / raw)
To: unicorn list
Matt Sanders <matt@modal.org> wrote:
> On Thu, Jul 19, 2012 at 6:13 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > Matt Sanders <matt@modal.org> wrote:
> >> 2. Is there an established way for adding an after_fork hook after
> >> Unicorn has already started up?
> >
> > Nothing that I know of.
> >
> >> I'm aware of the ability to do this via the config file but I don't
> >> want my users to have to add something to their unicorn config file.
> >> Is there an equivalent to passenger's
> >> PhusionPassenger.on_event(:starting_worker_process) method?
> >
> > Lately, I've been favoring the following pattern instead:
(top-posting corrected)
> Thanks! I definitely agree in general with that pattern. In this case
> I'd ideally like some activity on the forked child before the next
> request cycle - that is, if the forked child doesn't serve any
> requests for a little bit, I'd still like my behavior to be
> initialized.
Yes, that sucks. I'll often just throw some requests at the child
just to start something up if I need it, or initiate a separate daemon.
> Do you know of a way to get this behavior without a direct after fork hook?
No, unfortunately not. I have considered petitioning for something
along the lines of pthread_atfork() in Ruby, but pthread_atfork() itself
also has unfortunate drawbacks (it makes fork() async-signal un-safe,
and thus _Fork() will be introduced in the next version of POSIX).
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Any signal other than -9 causes full CPU utilization by master unicorn process on FreeBSD
@ 2012-07-17 0:33 3% Mark Mccraw
0 siblings, 0 replies; 200+ results
From: Mark Mccraw @ 2012-07-17 0:33 UTC (permalink / raw)
To: mongrel-unicorn@rubyforge.org
Hi There!
I'm having a devil of a time figuring out a weird issue I'm running into. I have unicorn configured to start 4 worker processes, and that works great. However, when it's time to cycle the app, everything goes haywire. By trial and error, I have narrowed it down to this: sending any signal to the master process other than SIGKILL fails miserably. No new master process is created, as described in the documentation, nothing happens to the existing workers, nothing gets written to any log, and if I run top -u, I can see that very quickly the master ramps up to 100% CPU utilization. This happens if I run 'kill -HUP <master pid>', 'kill -USR2 <master pid>', even 'kill -QUIT <master pid>'.
Here's what I'm running on:
uname -a
FreeBSD bb20web04.unx.sas.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
ruby -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [amd64-freebsd9]
gem list | grep unicorn
unicorn (4.3.1)
My unicorn.rb file is pasted at the bottom. It should be noted that I have tried every permutation of this I can think of to narrow out the problematic part (set preload_app to false, comment out preload_app), comment out before_exec, before_fork, after_fork, comment out the START_CTX[0] bit, etc), but things always fail the same way, so I'm guessing it's not the config, but I'm open to anything.
Any suggestions at all are greatly appreciated. I'd love to know how to interrupt the master process when it's slamming the CPU and get a stack trace, but I have no idea how in ruby. Any thoughts?
Thanks!
Mark
APP_ROOT="/usr/local/rails/partsdb/current"
working_directory APP_ROOT
pid "#{APP_ROOT}/tmp/pids/unicorn.pid"
stderr_path "#{APP_ROOT}/log/unicorn.log"
stdout_path "#{APP_ROOT}/log/unicorn.log"
Unicorn::HttpServer::START_CTX[0] = "#{APP_ROOT}/bin/unicorn"
rails_env = ENV['RAILS_ENV'] || 'production'
worker_processes 4
timeout 120
# Speed up worker spawn times
preload_app true
listen "/tmp/unicorn.sock", :backlog => 10
listen "bb20web04:8080", :backlog => 1024
before_exec do |server|
ENV["BUNDLE_GEMFILE"] = "#{APP_ROOT}/Gemfile"
end
before_fork do |server, worker|
##
# When sent a USR2, Unicorn will suffix its pidfile with .oldbin and
# immediately start loading up a new version of itself (loaded with a new
# version of our app). When this new Unicorn is completely loaded
# it will begin spawning workers. The first worker spawned will check to
# see if an .oldbin pidfile exists. If so, this means we've just booted up
# a new Unicorn and need to tell the old one that it can now die. To do so
# we send it a QUIT.
#
# Using this method we get 0 downtime deploys.
if defined?(ActiveRecord::Base)
ActiveRecord::Base.connection.disconnect!
end
old_pid = APP_ROOT + '/tmp/pids/unicorn.pid.oldbin'
if File.exists?(old_pid) && server.pid != old_pid
begin
Process.kill("QUIT", File.read(old_pid).to_i)
rescue Errno::ENOENT, Errno::ESRCH
# someone else did our job for us
end
end
end
after_fork do |server, worker|
##
# Unicorn master loads the app then forks off workers - because of the way
# Unix forking works, we need to make sure we aren't using any of the parent's
# sockets, e.g. db connection
if defined?(ActiveRecord::Base)
ActiveRecord::Base.establish_connection
end
# Redis and Memcached would go here but their connections are established
# on demand, so the master never opens a socket
end
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Unicorn workers under Monit
@ 2012-06-27 18:35 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2012-06-27 18:35 UTC (permalink / raw)
To: unicorn list
Manuel Palenciano Guerrero <mpalenciano@gmail.com> wrote:
> Hi there,
>
> I would like to config Monit to monitor our production-unicorn-workers
>
> What memory size would you recommend to be the maximum reachable for a
> worker? so Monit can restart it.
It depends :)
Memory size varies widely between applications/deployments.
It depends on your:
* application + libraries + gems (including framework used)
* Ruby implementation/version (MRI 1.8 vs 1.9 vs Rubinius)
* machine architecture (32-bit vs 64-bit)
* malloc implementation/tuning
...
I have seen deployments processes where 20-30M (RSS) per-worker was
expected and have also seen deployments where 300-400M was expected for
the application.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: [PATCH] `kill -SIGTRAP <worker pid>`
@ 2012-06-24 11:05 3% ` Cedric Maion
0 siblings, 0 replies; 200+ results
From: Cedric Maion @ 2012-06-24 11:05 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
> Please keep Subject lines a reasonable length (git recommends the commit
> message subject wrap at ~50 columns or so) and wrap code at <= 80
> columns
ok
> SIGKILL timeout is only a last line of defense when the Ruby VM itself
> is completely broken. Handling SIGTRAP implies the worker can still
> respond (and /can/ be rescued), so your SIGTRAP handler is worthless if
> SIGKILL is required to kill a process.
Sure. But if the VM is responding, being able to get a backtrace is nice.
And if it's stuck, you won't get anything indeed, but that's still an
information (in that case, one may eventually want to get a gdb
backtrace too). No?
> See http://unicorn.bogomips.org/Application_Timeouts.html
Yes, I'm well aware of this. However, when you still get rare unicorn
timeouts, debugging them is not obvious.
In my case, a server in a loadbalanced farm sometimes sees all it's
unicorn workers timeout in the same minute (approx once a day at what
seems a random time) -- other servers are fine. Couldn't correlate this
with any specific network/disk/misc system/user activity yet.
> Sleeping here is also unacceptable since it blocks the main loop,
> making masters signal handlers non-responsive for too long.
ok.
>
> Using the Logger class inside a signal handler can deadlock. Logger
> attempts to acquire a non-reentrant lock when called. Unicorn doesn't
> use threads itself, but the Rack app may use threads internally.
ok, can be replaced with a $stdout.write then.
> Thanks for your interest in unicorn!
Thanks for your feedback,
Kind regards,
Cedric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJP5vSRAAoJEA15MS+4e3PCyekH/2ffXVT5UrXt0t7iou6cH9kt
q2mDMIbotRZp2iB21K0H1QtPTgrU6h4TrfEyiz3bfgtMLDCbAcXQal6x78sjNqPh
lIzs78TKgjkzh5SfqwIAyVVXuuU5AtGJleQeG2opHTgrZUxDRSOpJGxq2sYZU/rC
OiCybOiYyh8nFudbg0v7BBTrYyCA/uWOO6zweGh0euJzrLrg0qeTMnexsEXzITkX
OWZS6ALNt6UUq/DRSfGk9ciuWes/za5NaXob/60qgyqOinDuMUaTrR+KXZfliCu0
69C/mh7qpSPc/n91qjzvjklfc9bTd2WiUPeODQLayyEZ5QVEVsLMS1zlCDlyXck=
=XeZq
-----END PGP SIGNATURE-----
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Sinatra app fails to perform at scale
2012-06-15 18:09 2% Sinatra app fails to perform at scale Eliot Shepard
@ 2012-06-15 21:22 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2012-06-15 21:22 UTC (permalink / raw)
To: unicorn list; +Cc: Eliot Shepard
Eliot Shepard <eshepard@slower.net> wrote:
> Hello,
>
> We're attempting to move our set of Rails and Sinatra apps from
> Passenger/REE to Unicorn/1.9.3. We've started with one of the Sinatra
> apps, which typically sees about 50 req/s. It happens to talk to both
> Redis (Resque) and MongoDB GridFS.
Are you having problems at 50 req/s or higher than that with ab?
> The basic setup works fine when tested under ab, but we're having
> trouble getting the deploy into production. It performs fine for a
> bit, then the nginx write queue fills up and begins returning 502s.
Is ab hitting nginx or unicorn? You'll probably get more
accurate/consistent results using ab with keepalive (-k) and hitting
nginx with ab.
> A colleague has posted a more detailed description of the issue and our
> setup on ServerFault:
> http://serverfault.com/questions/398972/need-to-increase-nginx-throughput-to-an-upstream-unix-socket-linux-kernel-tun
Fwiw, I don't (and don't intend to) monitor external websites for
questions, especially when they require signups. Feel free to post
my response in part or full (or link back to this ML archive).
I'll quote the relevant parts
<snip> nginx config looks fine.
The Unicorn config would be helpful here, too.
Can you try setting the listen:backlog directive to a higher number?
Something like:
listen "/tmp/app.sock", :backlog => 8192
You'll want to stay within your net.core.somaxconn = 8192 value or raise
that sysctl to match unicorn. However, if you have multiple machines
and want to load balance, I recommend trying a lower backlog.
> The issue is, it just seems that past a certain amount of load, nginx
> can't get requests through the socket at a fast enough rate. It doesn't
> matter how many app server processes I set up, it doesn't even matter
> what the app is (tried it with a dummy app with just a single endpoint
> that returned an empty page with status 404). The bottleneck seems to
> be the socket, not the app.
> I'm getting a flood of these messages in the nginx error log:
> connect() to unix:/tmp/app.sock failed (11: Resource temporarily
> unavailable) wh ile connecting to upstream
> Many requests result in status code 502, and those that don't take a
> long time to complete. The nginx write queue stat hovers around 1000.
Can you also verify unicorn is correctly closing connections that nginx
opens to it? unicorn 4.3.1 should be fine in this regard...
> Additional information on the environment
> curbed@app1:~$ uname -a
> Linux app1 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC
> 2012 x86_64 x86_64 x86_64 GNU/Linux
> curbed@app1:~$ ruby -v
> ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
> curbed@app1:~$ unicorn -v
> unicorn v4.3.1
> curbed@app1:~$ nginx -V
> nginx version: nginx/1.2.1
I haven't tested with nginx 1.2.x, yet, but I expect it to be fine.
I know 1.2.x also supports keepalive to backend connections, but
I don't expect it to benefit on a fast LAN or local Unix socket...
> Any suggestions on configuration, kernel tuning, etc. would be
> welcomed (here or on SF). Please CC me if you answer through the list.
> Thanks for your time.
Thanks for reminding us to Cc: :)
I think Tom had a similar question a few years ago
http://mid.gmane.org/20090918064831.GA5285@dcvr.yhbt.net
However, hitting issues with the default backlog (1024) with 50 req/s
wouldn't be expected...
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Sinatra app fails to perform at scale
@ 2012-06-15 18:09 2% Eliot Shepard
2012-06-15 21:22 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Eliot Shepard @ 2012-06-15 18:09 UTC (permalink / raw)
To: mongrel-unicorn
Hello,
We're attempting to move our set of Rails and Sinatra apps from
Passenger/REE to Unicorn/1.9.3. We've started with one of the Sinatra
apps, which typically sees about 50 req/s. It happens to talk to both
Redis (Resque) and MongoDB GridFS.
The basic setup works fine when tested under ab, but we're having
trouble getting the deploy into production. It performs fine for a
bit, then the nginx write queue fills up and begins returning 502s. A
colleague has posted a more detailed description of the issue and our
setup on ServerFault:
http://serverfault.com/questions/398972/need-to-increase-nginx-throughput-to-an-upstream-unix-socket-linux-kernel-tun
Additional information on the environment
curbed@app1:~$ uname -a
Linux app1 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux
curbed@app1:~$ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
curbed@app1:~$ unicorn -v
unicorn v4.3.1
curbed@app1:~$ nginx -V
nginx version: nginx/1.2.1
built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx --with-http_ssl_module
--with-cc-opt=-Wno-error --with-http_gzip_static_module
--with-http_stub_status_module
--add-module=/home/curbed/src/nginx-modules/nginx-gridfs
--add-module=/home/curbed/src/nginx-modules/ngx_http_redis-0.3.6
--add-module=/home/curbed/src/nginx-modules/headers-more-nginx-module
Kernel tweaks:
net.core.rmem_default = 65536
net.core.wmem_default = 65536
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_mem = 16777216 16777216 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.somaxconn = 8192
net.netfilter.nf_conntrack_max = 131072
Any suggestions on configuration, kernel tuning, etc. would be
welcomed (here or on SF). Please CC me if you answer through the list.
Thanks for your time.
Eliot
--
Eliot Shepard
Head of Tech, Curbed Network
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: unicorn 4 does not compile on Joyent (SmartOS/Solaris) due to raindrops dependency
2012-05-09 7:02 0% ` Eric Wong
@ 2012-05-09 7:11 0% ` Konstantin Gredeskoul
0 siblings, 0 replies; 200+ results
From: Konstantin Gredeskoul @ 2012-05-09 7:11 UTC (permalink / raw)
To: unicorn list
Eric, awesome and thanks for replying!
I'll email you privately to chase this down.
K
On Wed, May 9, 2012 at 12:02 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Konstantin Gredeskoul <kig@wanelo.com> wrote:
>> However, the raindrops dependency introduced in 4.0 breaks raindrops
>> (and therefore unicorn 4) on SmartOS.
>>
>> The fact that the compilation breaks in the file named
>> "linux_inet_diag.c" makes me believe that perhaps the authors may not
>> have anticipated usage beyond Linux, or there may be some other
>
> That file is Linux-specific, but the rest of raindrops (and unicorn)
> works on FreeBSD, OpenBSD and probably others. I have every expectation
> it'd work on SmartOS[1]
>
>> > uname -a
>> SunOS demo001.dev 5.11 joyent_XXXX i86pc i386 i86pc Solaris
> ^^^^
>
>> > file .rvm/rubies/ruby-1.9.3-p194/bin/ruby
>> .rvm/rubies/ruby-1.9.3-p194/bin/ruby: ELF 64-bit LSB executable
>> AMD64 Version 1, dynamically linked, not stripped
> ^^^^^
>
> Are you running a mixed 32-bit/64-bit installation?
> Can you check the build system isn't picking the wrong compiler
> or compiler flags?
>
>> make
>> compiling linux_inet_diag.c
>> linux_inet_diag.c:1:0: error: CPU you selected does not support x86-64
>> instruction set
>
> That's odd, the first line is just #include <ruby.h>
>
> You can try emptying/removing that file completely? (maybe
> linux_tcp_diag.c, too).
>
> Your env shouldn't define the __linux__ macro. The linux_* files is
> wrapped with an #ifdef __linux__, so those files shouldn't even
> be compiled on other OSes.
>
> The portable part of raindrops does use CPU-specific atomics
> (which GCC or libatomic_ops provides). Ruby 1.9.3 itself uses
> these instructions, too.
>
>
> [1] - SmartOS seems to be Free Software, so I can actually support it :)
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
--
Konstantin Gredeskoul
CTO :: Wanelo Inc
cell: (415) 265 1054
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: unicorn 4 does not compile on Joyent (SmartOS/Solaris) due to raindrops dependency
2012-05-09 6:18 3% unicorn 4 does not compile on Joyent (SmartOS/Solaris) due to raindrops dependency Konstantin Gredeskoul
@ 2012-05-09 7:02 0% ` Eric Wong
2012-05-09 7:11 0% ` Konstantin Gredeskoul
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2012-05-09 7:02 UTC (permalink / raw)
To: unicorn list
Konstantin Gredeskoul <kig@wanelo.com> wrote:
> However, the raindrops dependency introduced in 4.0 breaks raindrops
> (and therefore unicorn 4) on SmartOS.
>
> The fact that the compilation breaks in the file named
> "linux_inet_diag.c" makes me believe that perhaps the authors may not
> have anticipated usage beyond Linux, or there may be some other
That file is Linux-specific, but the rest of raindrops (and unicorn)
works on FreeBSD, OpenBSD and probably others. I have every expectation
it'd work on SmartOS[1]
> > uname -a
> SunOS demo001.dev 5.11 joyent_XXXX i86pc i386 i86pc Solaris
^^^^
> > file .rvm/rubies/ruby-1.9.3-p194/bin/ruby
> .rvm/rubies/ruby-1.9.3-p194/bin/ruby: ELF 64-bit LSB executable
> AMD64 Version 1, dynamically linked, not stripped
^^^^^
Are you running a mixed 32-bit/64-bit installation?
Can you check the build system isn't picking the wrong compiler
or compiler flags?
> make
> compiling linux_inet_diag.c
> linux_inet_diag.c:1:0: error: CPU you selected does not support x86-64
> instruction set
That's odd, the first line is just #include <ruby.h>
You can try emptying/removing that file completely? (maybe
linux_tcp_diag.c, too).
Your env shouldn't define the __linux__ macro. The linux_* files is
wrapped with an #ifdef __linux__, so those files shouldn't even
be compiled on other OSes.
The portable part of raindrops does use CPU-specific atomics
(which GCC or libatomic_ops provides). Ruby 1.9.3 itself uses
these instructions, too.
[1] - SmartOS seems to be Free Software, so I can actually support it :)
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* unicorn 4 does not compile on Joyent (SmartOS/Solaris) due to raindrops dependency
@ 2012-05-09 6:18 3% Konstantin Gredeskoul
2012-05-09 7:02 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Konstantin Gredeskoul @ 2012-05-09 6:18 UTC (permalink / raw)
To: mongrel-unicorn
Dear unicorn developer list,
I did a quick search online and couldn't find many reports, but I
thought I'd find out anyway.
Joyent cloud is a pretty awesomely fast cloud running on Solaris
derivative (SmartOS). Pretty much the entire ruby stack, including
imagemagick (the perennial nightmare) build without problems with ruby
1.9.3, as does unicorn up until version 3.7.0.
However, the raindrops dependency introduced in 4.0 breaks raindrops
(and therefore unicorn 4) on SmartOS.
The fact that the compilation breaks in the file named
"linux_inet_diag.c" makes me believe that perhaps the authors may not
have anticipated usage beyond Linux, or there may be some other
reason. In any case, it would be great to be able to run latest
unicorn on SmartOS, so if anyone has any suggestion please let me know
how. In the meantime we are running on 3.7.0.
Best regards,
Konstantin
> uname -a
SunOS demo001.dev 5.11 joyent_XXXX i86pc i386 i86pc Solaris
> file .rvm/rubies/ruby-1.9.3-p194/bin/ruby
.rvm/rubies/ruby-1.9.3-p194/bin/ruby: ELF 64-bit LSB executable
AMD64 Version 1, dynamically linked, not stripped
> gem install raindrops
Fetching: raindrops-0.8.0.gem (100%)
Building native extensions. This could take a while...
ERROR: Error installing raindrops:
ERROR: Failed to build gem native extension.
/home/wanelo/.rvm/rubies/ruby-1.9.3-p194/bin/ruby extconf.rb
checking for mmap() in sys/mman.h... yes
checking for munmap() in sys/mman.h... yes
checking for mremap() in sys/mman.h... no
checking for getpagesize() in unistd.h... yes
checking for rb_thread_blocking_region()... yes
checking for rb_thread_io_blocking_region()... yes
checking for GCC 4+ atomic builtins... yes
creating Makefile
make
compiling linux_inet_diag.c
linux_inet_diag.c:1:0: error: CPU you selected does not support x86-64
instruction set
linux_inet_diag.c:1:0: error: CPU you selected does not support x86-64
instruction set
make: *** [linux_inet_diag.o] Error 1
Gem files will remain installed in
/home/kig/.rvm/gems/ruby-1.9.3-p194/gems/raindrops-0.8.0 for
inspection.
Results logged to
/home/kig/.rvm/gems/ruby-1.9.3-p194/gems/raindrops-0.8.0/ext/raindrops/gem_make.out
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Socket errors and nginx 502 gateway errors
2012-04-29 19:18 0% ` Eric Wong
@ 2012-05-02 16:30 0% ` Pico Aeterna
0 siblings, 0 replies; 200+ results
From: Pico Aeterna @ 2012-05-02 16:30 UTC (permalink / raw)
To: unicorn list
Eric,
Thanks for your help. Was able to isolate the problem to a geoip gem.
I appreciate the tips and debugging help.
Thanks
Will
On Sun, Apr 29, 2012 at 12:18 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Pico Aeterna <flippedootninja@gmail.com> wrote:
>> reaped #<Process::Status: pid=9103,signaled(SIGIOT=6)> worker=9
>> /var/www/domain/releases/20120427011507/app/controllers/application_controller.rb:172:
>> [BUG] Segmentation fault
>
> OK, something (most likely your app) is causing Ruby to segfault.
> This is completely unrelated to nginx, so it'll be easier to hit
> unicorn directly to diagnose this.
>
> Since you're new to debugging, I'll try to walk you through dealing
> with core dumps:
>
> * Enable core dumps in the same shell process before starting unicorn
> (ulimit -c unlimited && unicorn -c /path/to/config ...)
>
> * On Linux, /proc/sys/kernel/core_* sysctls control where your core dumps
> are created.
>
> And when you get a core dump (a "core" or core.$PID file), you can run
> gdb on it:
>
> gdb /path/to/ruby /path/to/core
>
> Make sure you're using the same ruby binary that unicorn is using.
> Ruby should be compiled with debugging symbols ('-g' or '-ggdb') by
> default, but if not, you'll probably want to recompile.
>
>> 7369 writev(31, [{"GET
>> /widget/looks.js?id=1172821&thumbs=3&source=my_looks&gender=both&align=center&r=1320622693&hash=36189f21135680efbe2d076d0b56bb06
>> HTTP/1.0\r\nX-Forwarded
>> -For: 83.9.20.243, 83.9.20.243\r\nHost: domain.nu\r\nConnection:
>> close\r\nUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)
>> AppleWebKit/534.55.3 (KHTML, like Gecko) Version/5.1.5
>> Safari/534.55.3\r\nAccept: */*\r\nReferer:
>> http://www.xxxxx.com/\r\nAccept-Language: pl-PL\r\nAccept-Encoding:
>> gzip, deflate\r\nCookie:
>> __utma=78941577.1641012066.1319789648.1325094074.1325949868.3;
>> __utmz=78941577.1325949868.3.3.utmcsr=xxxx.com|utmccn=(referral)|utmcmd=referral|utmcct=/l.php;
>> __gads=ID=269c5cea8f09aea0:T=1319789648:S=ALNI_MaqwdMaIFS5I3FeqLnv86oivdVDuA;
>> __qca=P0-1390452860-1319789648200\r\n\r\n", 745}], 1) = 7457369
>
>> Using the following I was able to get a 200 response
>>
>> req='GET / HTTP/1.1\r\nHost: domain.com\r\n\r\n'
>> printf "$req" | socat - UNIX:/var/www/domain/shared/sockets/unicorn.sock
>
> OK, I think your printf request needs to more closely match what nginx
> is sending to trigger the segfault. I would add/remove
> headers/parameters you see above until things start segfaulting.
>
> With socat, you may also want to wait a bit for the response for
> slower endpoints:
>
> (printf "$req"; sleep $SECONDS) | socat - ...
>
> Otherwise socat will disconnect immediately after its written to
> the socket without waiting for a response.
>
> (a better, but complicated way would be to setup a FIFO as the
> integration tests in unicorn do).
>
> If you're familiar with Rack::Mock*, you may also want to isolate this
> to just a Rack application. It's likely the segfault can be triggered
> for your app without unicorn, too.
>
>> Sorry but i'm new to debugging Unicorn. Hopefully some of this is helpful.
>
> It is helpful. Debugging unicorn isn't different than debugging
> anything else. The most important is to understand the problem, and
> that's done by isolating variables to get a small, reproducible test
> case.
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Socket errors and nginx 502 gateway errors
2012-04-29 16:34 1% ` Pico Aeterna
@ 2012-04-29 19:18 0% ` Eric Wong
2012-05-02 16:30 0% ` Pico Aeterna
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2012-04-29 19:18 UTC (permalink / raw)
To: unicorn list
Pico Aeterna <flippedootninja@gmail.com> wrote:
> reaped #<Process::Status: pid=9103,signaled(SIGIOT=6)> worker=9
> /var/www/domain/releases/20120427011507/app/controllers/application_controller.rb:172:
> [BUG] Segmentation fault
OK, something (most likely your app) is causing Ruby to segfault.
This is completely unrelated to nginx, so it'll be easier to hit
unicorn directly to diagnose this.
Since you're new to debugging, I'll try to walk you through dealing
with core dumps:
* Enable core dumps in the same shell process before starting unicorn
(ulimit -c unlimited && unicorn -c /path/to/config ...)
* On Linux, /proc/sys/kernel/core_* sysctls control where your core dumps
are created.
And when you get a core dump (a "core" or core.$PID file), you can run
gdb on it:
gdb /path/to/ruby /path/to/core
Make sure you're using the same ruby binary that unicorn is using.
Ruby should be compiled with debugging symbols ('-g' or '-ggdb') by
default, but if not, you'll probably want to recompile.
> 7369 writev(31, [{"GET
> /widget/looks.js?id=1172821&thumbs=3&source=my_looks&gender=both&align=center&r=1320622693&hash=36189f21135680efbe2d076d0b56bb06
> HTTP/1.0\r\nX-Forwarded
> -For: 83.9.20.243, 83.9.20.243\r\nHost: domain.nu\r\nConnection:
> close\r\nUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)
> AppleWebKit/534.55.3 (KHTML, like Gecko) Version/5.1.5
> Safari/534.55.3\r\nAccept: */*\r\nReferer:
> http://www.xxxxx.com/\r\nAccept-Language: pl-PL\r\nAccept-Encoding:
> gzip, deflate\r\nCookie:
> __utma=78941577.1641012066.1319789648.1325094074.1325949868.3;
> __utmz=78941577.1325949868.3.3.utmcsr=xxxx.com|utmccn=(referral)|utmcmd=referral|utmcct=/l.php;
> __gads=ID=269c5cea8f09aea0:T=1319789648:S=ALNI_MaqwdMaIFS5I3FeqLnv86oivdVDuA;
> __qca=P0-1390452860-1319789648200\r\n\r\n", 745}], 1) = 7457369
> Using the following I was able to get a 200 response
>
> req='GET / HTTP/1.1\r\nHost: domain.com\r\n\r\n'
> printf "$req" | socat - UNIX:/var/www/domain/shared/sockets/unicorn.sock
OK, I think your printf request needs to more closely match what nginx
is sending to trigger the segfault. I would add/remove
headers/parameters you see above until things start segfaulting.
With socat, you may also want to wait a bit for the response for
slower endpoints:
(printf "$req"; sleep $SECONDS) | socat - ...
Otherwise socat will disconnect immediately after its written to
the socket without waiting for a response.
(a better, but complicated way would be to setup a FIFO as the
integration tests in unicorn do).
If you're familiar with Rack::Mock*, you may also want to isolate this
to just a Rack application. It's likely the segfault can be triggered
for your app without unicorn, too.
> Sorry but i'm new to debugging Unicorn. Hopefully some of this is helpful.
It is helpful. Debugging unicorn isn't different than debugging
anything else. The most important is to understand the problem, and
that's done by isolating variables to get a small, reproducible test
case.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Socket errors and nginx 502 gateway errors
@ 2012-04-29 16:34 1% ` Pico Aeterna
2012-04-29 19:18 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Pico Aeterna @ 2012-04-29 16:34 UTC (permalink / raw)
To: unicorn list
Eric,
Thanks for the response.
Unicorn Stderr Errorlog:
reaped #<Process::Status: pid=9103,signaled(SIGIOT=6)> worker=9
/var/www/domain/releases/20120427011507/app/controllers/application_controller.rb:172:
[BUG] Segmentation fault
ruby 1.8.7 (2011-02-18 patchlevel 334) [x86_64-linux], MBARI 0x6770,
Ruby Enterprise Edition 2011.03
Exception `Errno::EAGAIN' at
/var/www/domain/shared/bundle/ruby/1.8/gems/net-http-persistent-2.6/lib/net/http/faster.rb:15
- Resource temporarily unavailable
Exception `EOFError' at
/var/www/domain/shared/bundle/ruby/1.8/gems/net-http-persistent-2.6/lib/net/http/faster.rb:15
- end of file reached
Exception `Errno::EAGAIN' at
/var/www/domain/shared/bundle/ruby/1.8/gems/net-http-persistent-2.6/lib/net/http/faster.rb:15
- Resource temporarily unavailable
Exception `EOFError' at
/var/www/domain/shared/bundle/ruby/1.8/gems/net-http-persistent-2.6/lib/net/http/faster.rb:15
- end of file reached
Exception `TypeError' at
/var/www/domain/releases/20120427011507/app/views/search/_facet.html.erb:5
- can't convert String into Integer
Exception `ActionView::MissingTemplate' at
/var/www/domain/shared/bundle/ruby/1.8/gems/actionpack-2.3.11/lib/action_view/paths.rb:74
- Missing template widget/.erb in view path app/views
Exception `EOFError' at
/var/www/domain/shared/bundle/ruby/1.8/gems/newrelic_rpm-3.3.3/lib/new_relic/data_serialization.rb:111
- end of file reached
Exception `ActionView::MissingTemplate' at
/var/www/domain/shared/bundle/ruby/1.8/gems/actionpack-2.3.11/lib/action_view/paths.rb:74
- Missing template look/.erb in view path app/views
Exception `Memcached::NotFound' at
/var/www/domain/shared/bundle/ruby/1.8/gems/memcached-1.0.6/lib/memcached/memcached.rb:597
- Memcached::NotFound
Exception `Memcached::NotFound' at
/var/www/domain/shared/bundle/ruby/1.8/gems/memcached-1.0.6/lib/memcached/memcached.rb:525
- Memcached::NotFound
Exception `EOFError' at
/var/www/domain/shared/bundle/ruby/1.8/gems/newrelic_rpm-3.3.3/lib/new_relic/data_serialization.rb:111
- end of file reached
Exception `ActionView::MissingTemplate' at
/var/www/domain/shared/bundle/ruby/1.8/gems/actionpack-2.3.11/lib/action_view/paths.rb:74
- Missing template widget/.erb in view path app/views
Exception `ActionView::MissingTemplate' at
/var/www/domain/shared/bundle/ruby/1.8/gems/actionpack-2.3.11/lib/action_view/paths.rb:74
- Missing template widget/.erb in view path app/views
Exception `ActionView::MissingTemplate' at
/var/www/domain/shared/bundle/ruby/1.8/gems/actionpack-2.3.11/lib/action_view/paths.rb:74
- Missing template look/.erb in view path app/views
Exception `NoMethodError' at
/var/www/domain/releases/20120427011507/app/controllers/application_controller.rb:255
- undefined method `include?' for nil:NilClass
Exception `ActionView::MissingTemplate' at
/var/www/domain/shared/bundle/ruby/1.8/gems/actionpack-2.3.11/lib/action_view/paths.rb:74
- Missing template user/.erb in view path app/views
Exception `Memcached::NotFound' at
/var/www/domain/shared/bundle/ruby/1.8/gems/memcached-1.0.6/lib/memcached/memcached.rb:597
- Memcached::NotFound
Exception `Memcached::NotFound' at
/var/www/domain/shared/bundle/ruby/1.8/gems/memcached-1.0.6/lib/memcached/memcached.rb:597
- Memcached::NotFound
Strace with 2048 on nginx
7369 connect(31, {sa_family=AF_FILE,
path="/var/www/domain/shared/sockets/unicorn.sock"...}, 110) = 0
7369 getsockopt(31, SOL_SOCKET, SO_ERROR, [1424310214479314944], [4]) = 0
7369 writev(31, [{"GET
/widget/looks.js?id=1172821&thumbs=3&source=my_looks&gender=both&align=center&r=1320622693&hash=36189f21135680efbe2d076d0b56bb06
HTTP/1.0\r\nX-Forwarded
-For: 83.9.20.243, 83.9.20.243\r\nHost: domain.nu\r\nConnection:
close\r\nUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/534.55.3 (KHTML, like Gecko) Version/5.1.5
Safari/534.55.3\r\nAccept: */*\r\nReferer:
http://www.xxxxx.com/\r\nAccept-Language: pl-PL\r\nAccept-Encoding:
gzip, deflate\r\nCookie:
__utma=78941577.1641012066.1319789648.1325094074.1325949868.3;
__utmz=78941577.1325949868.3.3.utmcsr=xxxx.com|utmccn=(referral)|utmcmd=referral|utmcct=/l.php;
__gads=ID=269c5cea8f09aea0:T=1319789648:S=ALNI_MaqwdMaIFS5I3FeqLnv86oivdVDuA;
__qca=P0-1390452860-1319789648200\r\n\r\n", 745}], 1) = 7457369
epoll_wait(22, {{EPOLLOUT, {u32=2473377616, u64=46963645792080}}},
512, 17146) = 17369 epoll_wait(22, {{EPOLLIN|EPOLLOUT|EPOLLHUP,
{u32=2473377616, u64=46963645792080}}}, 512, 17146) = 17369
recvfrom(31, "", 4096, 0, NULL, NULL) = 0
7369 write(3, "2012/04/28 19:10:30 [error] 7369#0: *21954594 upstream
prematurely closed connection while reading response header from
upstream, client: 83.9.20.243, server: *.domain.nu, request: \"GET
/widget/looks.js?id=1172821&thumbs=3&source=my_looks&gender=both&align=center&r=1320622693&hash=36189f21135680efbe2d076d0b56bb06
HTTP/1.1\", upstream:
\"http://unix:/var/www/domain/shared/sockets/unicorn.sock:/widget/looks.js?id=1172821&thumbs=3&source=my_looks&nder=both&align=center&r=1320622693&hash=36189f21135680ef
be2d076d0b56bb06\", host: \"domain.nu\", referrer:
\"http://www.xxx.com/\"\n", 597) = 597
7369 close(31) = 0
7369 writev(20, [{"HTTP/1.1 502 Bad Gateway\r\nServer: nginx\r\nDate:
Sat, 28 Apr 2012 23:10:30 GMT\r\nContent-Type:
text/html\r\nContent-Length: 166\r\nConnection: close\r\n\r\n", 145},
{"<html>\r\n<head><title>502 Bad Gateway</title></head>\r\n<body
bgcolor=\"white\">\r\n<center><h1>502 Bad Gateway</h1></center>\r\n",
120}, {"<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n", 46}],
3) = 311
Using the following I was able to get a 200 response
req='GET / HTTP/1.1\r\nHost: domain.com\r\n\r\n'
printf "$req" | socat - UNIX:/var/www/domain/shared/sockets/unicorn.sock
HTTP/1.1 200 OK
Date: Sun, 29 Apr 2012 16:29:08 GMT
Status: 200 OK
Connection: close
ETag: "cc3c683b35f20547c69e8155279b3ecf"
Content-Type: text/html; charset=utf-8
X-Runtime: 227
Content-Length: 144433
Set-Cookie: _domain_session=BAh7CToKZ2VvaXBGOg9zZXNzaW9uX2lkIiU4NGIzYzkzZjUxNTAwYzUyZDhmYjkzOGM1YjhhNzUxNDoQbW9iaWxlX3ZpZXdGOgtsb2NhbGUiB2Vu--524e4c395bcfa87ca0ce0ab5bfb2f305d4a5f12b;
domain=.domain.com; path=/; HttpOnly
Cache-Control: private, max-age=0, must-revalidate
Sorry but i'm new to debugging Unicorn. Hopefully some of this is helpful.
Thanks
On Sat, Apr 28, 2012 at 2:59 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Pico Aeterna <flippedootninja@gmail.com> wrote:
>> Hi,
>>
>> We've been getting reports that our users have been getting random 502
>> Errors. After investigating I noticed 'upstream prematurely closed
>> connection while reading response header from upstream' in my nginx
>> error logs. From using strace it appears that there's numerous socket
>> SO_ERROR.. I temporarily switched out the domain sockets with TCP,
>> however am seeing the same result/issue.
>>
>> Strace and Nginx error log below:
>
> Can you show us an strace of a unicorn worker, too? (use
> "worker_processes 1" when debugging this)
>
> Also, the unicorn stderr log can be helpful.
>
>> 7366 epoll_ctl(16, EPOLL_CTL_ADD, 89, {EPOLLIN|EPOLLOUT|EPOLLET,
>> {u32=2473356496, u64=46963645770960}}) = 0
>> 7366 connect(89, {sa_family=AF_FILE,
>> path="/var/www/domain/shared/sockets/unicorn.sock"...}, 110) = 0
>> 7366 getsockopt(89, SOL_SOCKET, SO_ERROR, [1422340301959200768], [4]) = 0
>> 7366 writev(89, [{"GET /natalieliao HTTP/1.0\r\nX-Forwarded-For:
>> 94.224.228.239, 94.224.228.239\r\nHost"..., 1084}], 1) = 1084
>
> Can you pass "-s 2048" (or larger value) when stracing? It'll be
> helpful to know what else is in the HTTP header.
>
>> Load balancer (HaProxy) => nginx => unicorn
>
> Does hitting unicorn directly with curl (TCP) give an expected result?
> (You can use the strace output above to have curl mimic what nginx
> sends, or even use printf | socat which works with Unix sockets).
>
>> Relevant sysctl.conf changes
>
> Probably not relevant since you switched to Unix sockets, but
> consider default sysctl values while debugging (especially tcp_tw_*)
>
>> net.ipv4.ip_local_port_range = 1024 65535
>> net.ipv4.tcp_fin_timeout = 15
>> #timewait sockets
>> net.ipv4.tcp_tw_reuse = 1
>> net.ipv4.tcp_tw_recycle = 1
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 1%]
* Socket errors and nginx 502 gateway errors
@ 2012-04-28 21:33 3% Pico Aeterna
0 siblings, 1 reply; 200+ results
From: Pico Aeterna @ 2012-04-28 21:33 UTC (permalink / raw)
To: mongrel-unicorn
Hi,
We've been getting reports that our users have been getting random 502
Errors. After investigating I noticed 'upstream prematurely closed
connection while reading response header from upstream' in my nginx
error logs. From using strace it appears that there's numerous socket
SO_ERROR.. I temporarily switched out the domain sockets with TCP,
however am seeing the same result/issue.
Strace and Nginx error log below:
7366 epoll_ctl(16, EPOLL_CTL_ADD, 89, {EPOLLIN|EPOLLOUT|EPOLLET,
{u32=2473356496, u64=46963645770960}}) = 0
7366 connect(89, {sa_family=AF_FILE,
path="/var/www/domain/shared/sockets/unicorn.sock"...}, 110) = 0
7366 getsockopt(89, SOL_SOCKET, SO_ERROR, [1422340301959200768], [4]) = 0
7366 writev(89, [{"GET /natalieliao HTTP/1.0\r\nX-Forwarded-For:
94.224.228.239, 94.224.228.239\r\nHost"..., 1084}], 1) = 1084
7366 epoll_wait(16, {{EPOLLOUT, {u32=2473356496,
u64=46963645770960}}, {EPOLLOUT, {u32=2473355152,
u64=46963645769616}}}, 512, 4316) = 2
7366 recvfrom(88, 0x7fff856374b7, 1, 2, 0, 0) = -1 EAGAIN (Resource
temporarily unavailable)
7366 epoll_wait(16, {{EPOLLIN|EPOLLOUT|EPOLLHUP, {u32=2473356496,
u64=46963645770960}}}, 512, 4315) = 1
7366 recvfrom(89, "", 4096, 0, NULL, NULL) = 0
7366 write(3, "2012/04/28 17:14:45 [error] 7366#0: *21826315 upstream
prematurely closed connec"..., 319) = 319
7366 close(89) = 0
7366 stat("/var/www/domain/current/public/system/maintenance.html",
0x7fff85637210) = -1 ENOENT (No such file or directory)
7366 stat("/var/www/domain/current/public/500.html/index.html",
0x7fff85637190) = -1 ENOENT (No such file or directory)
7366 stat("/var/www/domain/current/public/500.html.html",
0x7fff85637190) = -1 ENOENT (No such file or directory)
7366 stat("/var/www/domain/current/public/500.html", 0x7fff85637190)
= -1 ENOENT (No such file or directory)
7366 socket(PF_FILE, SOCK_STREAM, 0) = 89
7366 ioctl(89, FIONBIO, [1]) = 0
7366 epoll_ctl(16, EPOLL_CTL_ADD, 89, {EPOLLIN|EPOLLOUT|EPOLLET,
{u32=2473356497, u64=46963645770961}}) = 0
7366 connect(89, {sa_family=AF_FILE,
path="/var/www/domain/shared/sockets/unicorn.sock"...}, 110) = 0
7366 getsockopt(89, SOL_SOCKET, SO_ERROR, [1422495985933746176], [4]) = 0
7366 writev(89, [{"GET /natalieliao HTTP/1.0\r\nX-Forwarded-For:
94.224.228.239, 94.224.228.239\r\nHost"..., 1084}], 1) = 1084
7366 epoll_wait(16, {{EPOLLOUT, {u32=2473356497,
u64=46963645770961}}}, 512, 4285) = 1
7366 epoll_wait(16, {{EPOLLIN|EPOLLOUT|EPOLLHUP, {u32=2473356497,
u64=46963645770961}}}, 512, 4284) = 1
7366 recvfrom(89, "", 4096, 0, NULL, NULL) = 0
7366 write(3, "2012/04/28 17:14:45 [error] 7366#0: *21826315 upstream
prematurely closed connec"..., 319) = 319
7366 close(89) = 0
7366 writev(88, [{"HTTP/1.1 502 Bad Gateway\r\nServer: nginx\r\nDate:
Sat, 28 Apr 2012 21:14:45 GMT\r\nCo"..., 145},
{"<html>\r\n<head><title>502 Bad Gateway</title></head>\r\n<body
bgcolor=\"white\">\r\n<ce"..., 120},
{"<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n", 46}], 3) =
311
7366 shutdown(88, 1 /* send */) = 0
2012/04/28 17:14:45 [error] 7366#0: *21826315 upstream prematurely
closed connection while reading response header from upstream,
client:94.224.228.239, server: *.domain.nu, request: "GET /natalieliao
HTTP/1.1", upstream:
"http://unix:/var/www/domain/shared/sockets/unicorn.sock:/natalieliao",
host: "domain.nu"
2012/04/28 17:14:45 [error] 7366#0: *21826315 upstream prematurely
closed connection while reading response header from upstream, client:
94.224.228.239, server: *.domain.nu, request: "GET /natalieliao
HTTP/1.1", upstream:
"http://unix:/var/www/domain/shared/sockets/unicorn.sock:/natalieliao",
host: "domain.nu"
Nginx information:
nginx version: nginx/1.0.15
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-52)
TLS SNI support disabled
configure arguments: --prefix=/etc/nginx --with-http_ssl_module
--sbin-path=/usr/sbin --http-log-path=/var/log/nginx/access.log
--error-log-path=/var/log/nginx/error.log --with-http_realip_module
--with-http_stub_status_module --pid-path=/var/run/nginx.pid
Unicorn information:
$ bundle show unicorn
/var/www/lookbook/shared/bundle/ruby/1.8/gems/unicorn-4.2.1
Ruby:
ruby:
interpreter: "ruby"
version: "1.8.7"
date: "2011-02-18"
platform: "x86_64-linux"
patchlevel: "2011-02-18 patchlevel 334"
full_version: "ruby 1.8.7 (2011-02-18 patchlevel 334)
[x86_64-linux], MBARI 0x6770, Ruby Enterprise Edition 2011.03"
Setup:
Load balancer (HaProxy) => nginx => unicorn
Relevant sysctl.conf changes
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_fin_timeout = 15
#timewait sockets
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.core.netdev_max_backlog = 4096
net.core.somaxconn = 4096
Just curious to know if there's a socket bug that I missed with the
current version of unicorn that's installed?
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: app error: Socket is not connected (Errno::ENOTCONN)
2012-04-27 19:51 3% ` Eric Wong
2012-04-27 19:53 0% ` Eric Wong
@ 2012-04-27 20:30 0% ` Matt Smith
1 sibling, 0 replies; 200+ results
From: Matt Smith @ 2012-04-27 20:30 UTC (permalink / raw)
To: Eric Wong; +Cc: mongrel-unicorn, George, Joel Nimety
On Fri, Apr 27, 2012 at 12:51 PM, Eric Wong <normalperson@yhbt.net> wrote:
> George <lists@SouthernOhio.net> wrote:
>> Just fyi, my dev logs are now rife with these: http://j.mp/IezMAu
>>
>> Will plug your patch in, but will have to figure out another option for
>> heroku deployment.
>
> Is this affecting your heroku deployment? What OS/kernel version
> are you running? From what Joel and Matt say, it could be more likely
> to trigger on *BSD-based systems.
I just tried on a 64-bit Ubuntu 11.10 (kernel 3.0.0-17-generic), ruby
1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]. No issue. Reloaded
a several pages, many times. No ENOTCONN. Not one. Same app.
Neither on ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux].
BSD issue?
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: app error: Socket is not connected (Errno::ENOTCONN)
[not found] ` <CACsAZRR=NP4O+EB0koAr0aeUwth=M+5aQnA8vtVLEXqFHd=jnA@mail.gmail.com>
@ 2012-04-27 19:51 3% ` Eric Wong
2012-04-27 19:53 0% ` Eric Wong
2012-04-27 20:30 0% ` Matt Smith
0 siblings, 2 replies; 200+ results
From: Eric Wong @ 2012-04-27 19:51 UTC (permalink / raw)
To: George; +Cc: mongrel-unicorn, Matt Smith, Joel Nimety
George <lists@SouthernOhio.net> wrote:
> Just fyi, my dev logs are now rife with these: http://j.mp/IezMAu
>
> Will plug your patch in, but will have to figure out another option for
> heroku deployment.
Is this affecting your heroku deployment? What OS/kernel version
are you running? From what Joel and Matt say, it could be more likely
to trigger on *BSD-based systems.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: app error: Socket is not connected (Errno::ENOTCONN)
2012-04-27 19:51 3% ` Eric Wong
@ 2012-04-27 19:53 0% ` Eric Wong
2012-04-27 20:30 0% ` Matt Smith
1 sibling, 0 replies; 200+ results
From: Eric Wong @ 2012-04-27 19:53 UTC (permalink / raw)
To: mongrel-unicorn; +Cc: Joel Nimety, George, Matt Smith
Eric Wong <normalperson@yhbt.net> wrote:
> George <lists@SouthernOhio.net> wrote:
> > Just fyi, my dev logs are now rife with these: http://j.mp/IezMAu
> >
> > Will plug your patch in, but will have to figure out another option for
> > heroku deployment.
>
> Is this affecting your heroku deployment? What OS/kernel version
> are you running? From what Joel and Matt say, it could be more likely
> to trigger on *BSD-based systems.
Also, if you revert my previous patch, does this also prevent the error
from manifesting?
(I expect ignoring ENOTCONN _once_in_a_while_ will be required,
but definitely not every request).
diff --git a/lib/unicorn/http_server.rb b/lib/unicorn/http_server.rb
index 14a6f9a..bb91e7f 100644
--- a/lib/unicorn/http_server.rb
+++ b/lib/unicorn/http_server.rb
@@ -537,7 +537,7 @@ class Unicorn::HttpServer
end
@request.headers? or headers = nil
http_response_write(client, status, headers, body)
- client.shutdown # in case of fork() in Rack app
+ client.close_write # in case of fork() in Rack app
client.close # flush and uncork socket immediately, no keepalive
rescue => e
handle_error(client, e)
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 0%]
* Re: app error: Socket is not connected (Errno::ENOTCONN)
2012-04-27 19:32 3% ` Eric Wong
2012-04-27 19:45 4% ` Matt Smith
@ 2012-04-27 19:47 0% ` Joel Nimety
1 sibling, 0 replies; 200+ results
From: Joel Nimety @ 2012-04-27 19:47 UTC (permalink / raw)
To: Eric Wong; +Cc: mongrel-unicorn, George, Matt Smith
On Fri, Apr 27, 2012 at 3:32 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Joel Nimety <jnimety@continuity.net> wrote:
>> On Fri, Apr 27, 2012 at 2:59 PM, Eric Wong <normalperson@yhbt.net> wrote:
>> > Joel Nimety <jnimety@continuity.net> wrote:
>> >> I'm getting the following errors multiple times per request when using
>> >> 4.3.0. I do not receive any errors when using 4.2.1. Please CC me on
>> >> replies, I'm not subscribed to the mailing list.
>> >
>> > Multiple times per request? Yikes. This can be expected occasionally.
>>
>> 46 times in development on the last request I tested. I can provide
>> my Gemfile, logs and any other debug info if you like. Just to
>> reiterate, if I downgrade to 4.2.1 I don't see the error at all.
>
> Yes, the addition of the shutdown() call[1] in 4.3.0 can cause ENOTCONN
> occasionally.
>
> Ignoring the exception works, but given the cost of generating
> exceptions in Ruby in the first place (especially 1.9), I don't
> think it's a good idea...
>
> I can't reproduce this error. Are you on a UNIX listener or TCP
> listene? What environment (OS/kernel version) is this?
OS X 10.7.3, ruby 1.9.3p125 (2012-02-16 revision 34643)
[x86_64-darwin11.3.0] with the latest command line x code. tcp, using
the the following config. I've tried removing preload_app but it
didn't help.
listen 3000
worker_processes 4
preload_app true
timeout 30
>
>
> [1] see thread starting here about adding shutdown():
> http://mid.gmane.org/CAOG6bOTseAPbjU5LYchODqjdF3-Ez4+M8jo-D_D2Wq0jkdc4Rw@mail.gmail.com
--
Joel Nimety
SVP Technology
Continuity Control
203.285.8133 (office)
203.763.9263 (cell)
http://www.continuity.net
http://www.linkedin.com/in/jnimety
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: app error: Socket is not connected (Errno::ENOTCONN)
2012-04-27 19:32 3% ` Eric Wong
@ 2012-04-27 19:45 4% ` Matt Smith
2012-04-27 19:47 0% ` Joel Nimety
1 sibling, 0 replies; 200+ results
From: Matt Smith @ 2012-04-27 19:45 UTC (permalink / raw)
To: Eric Wong; +Cc: mongrel-unicorn, George, Joel Nimety
> Yes, the addition of the shutdown() call[1] in 4.3.0 can cause ENOTCONN
> occasionally.
>
> Ignoring the exception works, but given the cost of generating
> exceptions in Ruby in the first place (especially 1.9), I don't
> think it's a good idea...
>
> I can't reproduce this error. Are you on a UNIX listener or TCP
> listene? What environment (OS/kernel version) is this?
I am running OS X 10.7.3, ruby 1.9.3p194 (2012-04-20 revision 35410)
[x86_64-darwin11.3.0]. I was going to try it on my linux dev machine
in a bit. I can get you kernel version then, if it occurs. I am just
running unicorn in local dev and hitting it with a browser (Safari
Version 5.1.5 (7534.55.3)) on localhost:8080.
In production, I use a UNIX listener. (I am seeing no errors in production.)
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 4%]
* Re: app error: Socket is not connected (Errno::ENOTCONN)
@ 2012-04-27 19:32 3% ` Eric Wong
2012-04-27 19:45 4% ` Matt Smith
2012-04-27 19:47 0% ` Joel Nimety
0 siblings, 2 replies; 200+ results
From: Eric Wong @ 2012-04-27 19:32 UTC (permalink / raw)
To: mongrel-unicorn; +Cc: Matt Smith, George, Joel Nimety
Joel Nimety <jnimety@continuity.net> wrote:
> On Fri, Apr 27, 2012 at 2:59 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > Joel Nimety <jnimety@continuity.net> wrote:
> >> I'm getting the following errors multiple times per request when using
> >> 4.3.0. I do not receive any errors when using 4.2.1. Please CC me on
> >> replies, I'm not subscribed to the mailing list.
> >
> > Multiple times per request? Yikes. This can be expected occasionally.
>
> 46 times in development on the last request I tested. I can provide
> my Gemfile, logs and any other debug info if you like. Just to
> reiterate, if I downgrade to 4.2.1 I don't see the error at all.
Yes, the addition of the shutdown() call[1] in 4.3.0 can cause ENOTCONN
occasionally.
Ignoring the exception works, but given the cost of generating
exceptions in Ruby in the first place (especially 1.9), I don't
think it's a good idea...
I can't reproduce this error. Are you on a UNIX listener or TCP
listene? What environment (OS/kernel version) is this?
[1] see thread starting here about adding shutdown():
http://mid.gmane.org/CAOG6bOTseAPbjU5LYchODqjdF3-Ez4+M8jo-D_D2Wq0jkdc4Rw@mail.gmail.com
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Unicorn_rails ignores USR2 signal
@ 2012-03-30 22:51 3% ` Alex Sharp
0 siblings, 0 replies; 200+ results
From: Alex Sharp @ 2012-03-30 22:51 UTC (permalink / raw)
To: unicorn list
Hey Jeffrey, we had a similar problem about 8 months ago. What version of ruby (including patch number) are you using? I think you said you're not using anything special in your deployment environment, right? You're not using god, by chance to do the restarts, are you?
Also, how are you doing your deployments, if not with cap?
--
Alex Sharp
Zaarly, Inc | @ajsharp | github.com/ajsharp | alexjsharp.com
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* RE: Unicorn_rails ignores USR2 signal
2012-03-09 22:24 0% ` Eric Wong
@ 2012-03-09 22:39 0% ` Yeung, Jeffrey
0 siblings, 1 reply; 200+ results
From: Yeung, Jeffrey @ 2012-03-09 22:39 UTC (permalink / raw)
To: Eric Wong, unicorn list
Thanks Eric. New strace capture as follows:
$ sudo strace -f -e '!futex' -p 14255
Process 14255 attached with 12 threads - interrupt to quit
[pid 14322] restart_syscall(<... resuming interrupted call ...> <unfinished ...>
[pid 14271] restart_syscall(<... resuming interrupted call ...> <unfinished ...>
[pid 14267] accept(12, <unfinished ...>
[pid 14264] restart_syscall(<... resuming interrupted call ...> <unfinished ...>
[pid 14255] select(6, [5], NULL, NULL, {42, 86504} <unfinished ...>
[pid 14322] <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed out)
[pid 14271] <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed out)
[pid 14264] <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed out)
[pid 14262] --- SIGUSR2 (User defined signal 2) @ 0 (0) ---
[pid 14262] rt_sigreturn(0x20) = 202
The last two lines do not say much for the event. :(
-----Original Message-----
From: Eric Wong [mailto:normalperson@yhbt.net]
Sent: Friday, March 09, 2012 2:24 PM
To: unicorn list
Cc: Yeung, Jeffrey
Subject: Re: Unicorn_rails ignores USR2 signal
"Yeung, Jeffrey" <Jeffrey.Yeung@polycom.com> wrote:
> $ ruby -v
> ruby 1.9.1p376 (2009-12-07 revision 26041) [x86_64-linux]
>
> The Rails gem version is 2.3.14. Unicorn gem version 4.2.0.
> I have done my best to debug it using strace and the stderr logs. The
> unicorn_rails master process handles HUP, QUIT, and USR1 signals as
> expected, no problems. However, the USR2 signal is being completely
> ignored.
> While monitoring the master with strace, there are no calls observed
> when sending a kill -USR2. Nothing is logged to STDERR when sending
> this signal, either.
Really strange, especially since other signals seem to work...
Since you're on Ruby (>= 1.9.0 && < 1.9.3), are you stracing with -f?
If you're not already, try using: strace -f -e '!futex'
1.9.x versions use a dedicated timer thread to accept signals, so you won't see system signal handlers in the VM without "strace -f".
The "-e '!futex'" filters out the noise from the polling wakeup in
<1.9.3 versions of Ruby.
Can you try Ruby 1.9.3? The signal handling got completely reworked (for the better) and you won't need "-e '!futex'"
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Unicorn_rails ignores USR2 signal
2012-03-09 21:48 3% Unicorn_rails ignores USR2 signal Yeung, Jeffrey
@ 2012-03-09 22:24 0% ` Eric Wong
2012-03-09 22:39 0% ` Yeung, Jeffrey
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2012-03-09 22:24 UTC (permalink / raw)
To: unicorn list; +Cc: Yeung, Jeffrey
"Yeung, Jeffrey" <Jeffrey.Yeung@polycom.com> wrote:
> $ ruby -v
> ruby 1.9.1p376 (2009-12-07 revision 26041) [x86_64-linux]
>
> The Rails gem version is 2.3.14. Unicorn gem version 4.2.0.
> I have done my best to debug it using strace and the stderr logs. The
> unicorn_rails master process handles HUP, QUIT, and USR1 signals as
> expected, no problems. However, the USR2 signal is being completely
> ignored.
> While monitoring the master with strace, there are no calls observed
> when sending a kill -USR2. Nothing is logged to STDERR when sending
> this signal, either.
Really strange, especially since other signals seem to work...
Since you're on Ruby (>= 1.9.0 && < 1.9.3), are you stracing with -f?
If you're not already, try using: strace -f -e '!futex'
1.9.x versions use a dedicated timer thread to accept signals, so you
won't see system signal handlers in the VM without "strace -f".
The "-e '!futex'" filters out the noise from the polling wakeup in
<1.9.3 versions of Ruby.
Can you try Ruby 1.9.3? The signal handling got completely reworked
(for the better) and you won't need "-e '!futex'"
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Unicorn_rails ignores USR2 signal
@ 2012-03-09 21:48 3% Yeung, Jeffrey
2012-03-09 22:24 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Yeung, Jeffrey @ 2012-03-09 21:48 UTC (permalink / raw)
To: mongrel-unicorn@rubyforge.org
Hi,
I have a problem with one of my Rails servers where the daemonized unicorn_rails master seems to completely ignores the USR2 signal (only).
First, about the environment. I've searched for solutions to this problem for several day now, and my situation appears to differ from most in that my environment is not using RVM, bundler, Capistrano, or other sandboxing tools. It's a fairly plain jane Rails deployment. The OS is 64-bit Ubuntu 10.04 server.
$ uname -a
Linux 2.6.32-37-server #81-Ubuntu SMP Fri Dec 2 20:49:12 UTC 2011 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04.4 LTS
Release: 10.04
Codename: lucid
$ ruby -v
ruby 1.9.1p376 (2009-12-07 revision 26041) [x86_64-linux]
The Rails gem version is 2.3.14. Unicorn gem version 4.2.0.
The Unicorn config includes "preload_app true". We use the same Unicorn configs on similar servers and for some yet unknown reason, this one is seeing a problem with USR2.
I have done my best to debug it using strace and the stderr logs. The unicorn_rails master process handles HUP, QUIT, and USR1 signals as expected, no problems. However, the USR2 signal is being completely ignored.
I added a before_exec block in the Unicorn conf with some puts statements, but this hook never gets called (unlike the before_fork and after_fork hooks, which are working fine for me).
before_exec do |server|
$stderr.puts("DEBUG before_exec")
$stderr.puts(ENV.inspect)
$stderr.puts(Unicorn::HttpServer::START_CTX.inspect)
end
While monitoring the master with strace, there are no calls observed when sending a kill -USR2. Nothing is logged to STDERR when sending this signal, either.
This has me completely stymied with the lack of logging info. Does anyone have any clues that can point me in the right direction?
-Jeff
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: murdering high-memory workers and auto-scaling
@ 2012-03-02 1:07 2% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2012-03-02 1:07 UTC (permalink / raw)
To: unicorn list
Ben Somers <somers.ben@gmail.com> wrote:
> Two ideas, one more controversial than the other.
Neither is really controversal.
> First: auto-killing bloated workers. My current app has some memory
> leakage that wasn't really visible on our older passenger setup, since
> the auto-scaling meant that bloated workers got killed periodically.
> In a perfect world, we'd find and patch all of the leaks, but in the
> meantime (and as a safety net) I'd like to get the bloated workers
> auto-killed. It looks like it'd be simple to add in a bloated-worker
> check at the same point when we check for timeout violations, and it
> could be hidden behind a config setting. Alternately, I could write
> this in a separate script.
>
> Pros: might be a useful built-in feature, looks easy to implement the killing
> Cons: Getting the memory usage might actually be surprisingly
> difficult. Comparing to passenger's memory management code, where they
> actually use platform-specific system calls, and we might get a
> sizeable quantity of code that we don't want dirtying up the unicorn
> internals. Also, some methods of checking appear to have performance
> risks.
You can try something like the following middleware (totally untested,
but I've done similar things here and there). I don't know about
non-Linux, but I suspect /proc/#$$/* is likely to have something
similar...
class MemCheckLinux < Struct.new(:app)
def call(env)
# a faster, but less-readable version may use /proc/#$$/stat or
# /proc/#$$/statm but those aren't as human-friendly as
# /proc/#$$/status
if /VmRSS:\s+(\d+)\s/ =~ File.read("/proc/#$$/status")
# gracefully kill ourselves if we exceed ~100M
Process.kill(:QUIT, $$) if $1.to_i > 100_000
end
app.call(env)
end
end
use MemCheckLinux
run Rack::Lobster.new
Sadly, setrlimit(:RLIMIT_AS) only causes SIGSEGV to get raised,
and Ruby controls that signal for itself. I sometimes use
setrlimit(:RLIMIT_CPU) + trap(:XCPU) to kill runaway processes.
Apache has long had a similar parameter where you could just
tell a worker to gracefully die after X number of requests. That'd
also be trivial to implement with middlware using SIGQUIT.
> Second: in my use case, I have webservers running as VMs, sharing a
> physical box with backend utility servers. The util servers run lots
> of very CPU- and memory-hungry jobs, mostly at night; the webservers
> handle requests, mostly in the daytime. Currently, most of these
> webservers are running passenger, which is very polite about not using
> more resources than it needs to handle requests. Unicorn, by contrast
> (and by design) is very resource-greedy, what with the "scale to what
> you can theoretically handle" strategy. If I spin down my number of
> unicorn workers when they're not needed, I free up resources for my
> util servers, which is important. TTOU and TTIN signals give me a
> (very nice) means to write an auto-scaling module outside of unicorn,
> but it might be nice to have it included as an optional component. (I
> expect this will get voted down, as I expect the dev team is not
> interested in it).
If you can make an effort to support it when it breaks, I wouldn't mind
including a script in the examples/ section or as an optional module.
It's definitely not going to ever be the default. Auto-scaling is hard
(if not impossible) to get right. In my experience, it always get
things wrong by default or gets configured wrong, making things more
difficult to fix.
Dedicated servers will always be the primary target of unicorn.
(And unicorn of course only scales to server + backend resources,
nginx handles scaling to client connections :)
> Happy to work on implementing these myself, just wanted to poll to see
> if it'd be worth developing them as part of unicorn proper rather than
> standalone scripts.
If you're willing to help support users of these scripts/modules,
I'd have no reservations about distributing them along with unicorn.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: using unicorn as a local development server
@ 2012-02-24 23:10 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2012-02-24 23:10 UTC (permalink / raw)
To: unicorn list
Matt Smith <matt@nearapogee.com> wrote:
> Eric Wong wrote:
> > Normally I just write integration tests (sometimes starting unicorn (or
> > zbatery) + hitting it with curl, but often just mocking a Rack env).
> > Unlike most folks that develop apps that run over HTTP, I have a strong
> > aversion to web browsers. I'd rather pipe curl output to "vim -" if I
> > have to look at any text output from the application.
>
> This is slightly off topic, so I will make this concise, or this can
> be taken offline.
>
> What you are talking about, Eric, is exactly the workflow I am working
> toward. I am almost there, but still too dependent on the browser. So
> 2 questions:
> 1) Would you share what you use for integrations tests for rails and
> rack apps in general? (rack test, minitest, capybara, etc.)
For Rack apps, I normally use test/unit (minitest in 1.9) + Rack::Mock*.
test/test_watcher.rb in raindrops[1] is a public example of that.
I don't develop a lot of Rack apps, though. I haven't touched Rails in
ages, but last time I used test/unit and some builtin Rails test
extensions.
If I'm testing within Ruby, I stay with test/unit because it's
bundled/maintained with the latest version(s) of Ruby. Back in the day,
I know some projects had trouble migrating to Ruby 1.9.1 because rspec
wasn't 1.9-compatible at the time (it is now).
Back to Unicorn (and Rainbows!)
-------------------------------
For testing HTTP servers (or anything that interacts with
non-Ruby-components), I'll use scripts in other languages
(shell/Perl/awk) and external tools (e.g. curl) to shake out potential
bugs.
I worry about "self-cancelling" bugs which can be hidden from tests
because I didn't understand something (often Ruby itself) well enough.
Ruby 1.9 encodings is/was especially confusing to me, so I reached
outside of Ruby in many cases.
[1] - git clone git://bogomips.org/raindrops
[2] - For the few Rack apps I write, almost all of them are APIs or
targeted at lynx or curl users. I hate pretty things :)
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: FreeBSD jail and unicorn
@ 2012-02-07 7:36 3% ` Philipp Bruell
0 siblings, 0 replies; 200+ results
From: Philipp Bruell @ 2012-02-07 7:36 UTC (permalink / raw)
To: unicorn list
Hi,
Sorry for my late rely.
On 07/02/2012 07:21, "Eric Wong" <normalperson@yhbt.net> wrote:
>Eric Wong <normalperson@yhbt.net> wrote:
>> ruby-core pointed me to the following issue:
>> https://bugs.ruby-lang.org/issues/5757
>>
>> So there may already be a fix in Ruby SVN, can you test?
>> http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_9_3 r34425
>
>Btw, did anybody get a chance to try this?
I haven't tried it yet. Currently, we are using RVM to install ruby, but
as soon as I've some time, I'll setup a source version of ruby and apply
some of these patches.
>
>While working on an unrelated project, I setup FreeBSD 8.2 and 9.0
>KVM images over the weekend. Since I had the KVM images handy, I also
>tried to reproduce this issue under 1.9.3-p0 (without a jail) but was
>unable to reproduce the issue under either 8.2 nor 9.0.
Yeah - I've also ask a college to test it under FreeBSD (without Jail) and
he can't reproduce it either. It seems to be a Jail problem (I would run
in cycles too, if I would be in Jail ;-).
>I tried building a jail, but didn't have enough space for a full one.
>If I get the chance, I'll see how building a partial jail goes, but I'm
>not optimistic about being able to reproduce this issue under KVM
>since it seems to be a race condition/timing issue.
>
>I even had both CPU cores enabled under KVM and even installed the
>virtio drivers for better performance.
>
>I assume you guys are using SMP in the jail?
Yes - I'm pretty sure that SMP is involved.
Kind regards
Philipp
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: FreeBSD jail and unicorn
[not found] ` <CB5014D7.892%philipp.bruell@skrill.com>
@ 2012-02-02 19:31 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2012-02-02 19:31 UTC (permalink / raw)
To: unicorn list; +Cc: Philipp Bruell, Charles Hornberger
Philipp Bruell <Philipp.Bruell@skrill.com> wrote:
> On 01/02/2012 19:14, "Eric Wong" <normalperson@yhbt.net> wrote:
> >Philipp Bruell <Philipp.Bruell@skrill.com> wrote:
> The scripts behaves exactly like unicorn. The master received the QUIT and
> passes it to the child. The child also receives it, but don't exit. While
> the master is waiting for the child to exit, it consumes all the cpu
> cycles.
Interesting, I suspect it's some bad interaction with fork() causing
signal handlers/pthreads to go bad. I expect the following simple
script to work flawlessly since it doesn't fork:
----------------------------------------
trap(:QUIT) { exit(0) }
puts "Ready for SIGQUIT on #$$"
sleep
----------------------------------------
> I don't have the option, to test without jail, on a different FreeBSD
> version nor a different architecture (and FreeBSD - on Mac OS X everything
> works perfect). But I tried ruby version 1.9.2 and that works! So I guess
> it's a bug with 1.9.3 on FreeBSD.
Can you report this as a bug to the Ruby core folks on
https://bugs.ruby-lang.org/ and also to whereever the FreeBSD hackers
take bug reports? Somebody from one of those camps should be able
to resolve the issue.
The good thing is my small sample script is enough to reproduce the
issue, so it should be easy for an experienced FreeBSD hacker to
track down.
> I've attached the truss -f output of the child process of the test script.
> But the observation with truss made the problem disappear again :-(
It could be a timing or race condition issue. I've had strace on linux
find/hide bugs because it slowed the program down enough.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: FreeBSD jail and unicorn
[not found] ` <CB4EBD2A.7DF%philipp.bruell@skrill.com>
@ 2012-02-01 18:14 3% ` Eric Wong
[not found] ` <CB5014D7.892%philipp.bruell@skrill.com>
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2012-02-01 18:14 UTC (permalink / raw)
To: unicorn list; +Cc: Philipp Bruell, Charles Hornberger
Philipp Bruell <Philipp.Bruell@skrill.com> wrote:
> First of all, thank you for your fast reply.
No problem, depends on the time of day of course :>
> The behaviour details Charles described are correct and we are using ruby
> version 1.9.3.
>
> It's good that you've asked for the other signals. I've checked them in
> particular and it seems that it is a common signal handling problem. The
> process freaks out on each of them :-(
>
> I've attached the output of truss -f for a QUIT signal. That signal took a
> quite long time to get processed (and took all CPU cycles), but finally
> worked.
I only saw the output from the master process there, nothing from the
worker. It seems like the master is OK, but trying to kill the worker
is not. I wonder if it's related to
https://bugs.ruby-lang.org/issues/5240
With the following script, can you try sending SIGQUIT to the parent
and see what happens?
------------------------------- 8< -----------------------------
pid = fork do
r, w = IO.pipe
trap(:QUIT) do
puts "SIGQUIT received in child, exiting"
w.close
end
r.read
end
trap(:QUIT) do
puts "SIGQUIT received in parent, killing child"
Process.kill(:QUIT, pid)
p Process.waitpid2(pid)
exit
end
sleep 1 # wait for child to setup sig handler
puts "Child ready on #{pid}, parent on #$$"
sleep
----------------------------------------------------------------
If the above fails, try with different variables:
* without a jail on the same FreeBSD version/release/patchlevel
* Ruby 1.9.2 (which has a different signal handling implementation)
* different FreeBSD version
* different architecture[1]
Mixing either signal handling or fork()-ing in the presence of threads
is tricky. Ruby 1.9 uses a dedicated thread internally for signal
handling, I wouldn't be surprised if there's a bug lingering somewhere
in FreeBSD or Ruby...
Have you checked the FreeBSD mailing lists/bug trackers? I don't recall
seeing anything other than the aforementioned bug in ruby-core...
[1] - I expect there's ASM involved in signal/threading implementation
details, so there's a chance it's x86_64-specific...
> The output of USR2 signal is too long to attach it to a mail, but at a
> first sight, it repeats the following calls over and over again.
Don't send monster attachments, host it somewhere else so mail servers
won't reject it for wasting bandwidth. The mailman limit on rubyforge
is apparently 256K (already huge IMHO). Also, don't top post
> 24864:
> thr_kill(0x18c32,0x1a,0x800a8edc0,0x18a86,0x7fffffbeaf80,0x80480c000) = 0
> (0x0)
> 24864: select(4,{3},0x0,0x0,{0.100000 }) = 1 (0x1)
> 24864: read(3,"!",1024) = 1 (0x1)
OK, so the signal is received correctly by the Ruby VM in the master.
I just don't see anything in the worker, but the master does attempt
to forward SIGQUIT to the worker.
> It also seems to me, that observing the processes with truss changes the
> behaviour a lot. During the observed USR2 the master process spawns a lot
> (about 30) of <defunct> processes. I never had this before.
Some processes react strangely to being traced. Maybe there's something
better than truss nowadays?
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: FreeBSD jail and unicorn
@ 2012-01-31 19:05 3% ` Eric Wong
[not found] ` <CB4EBD2A.7DF%philipp.bruell@skrill.com>
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2012-01-31 19:05 UTC (permalink / raw)
To: Charles Hornberger; +Cc: unicorn list, Philipp Bruell
Charles Hornberger <Charles.Hornberger@skrill.com> wrote:
> On 1/31/12 7:39 PM, normalperson@yhbt.net wrote:
> >If that didn't work, maybe checking stderr.log will tell you something
> >more.
>
> Nothing shows up in stderr.log It's as if the master doesn't even get the
> -USR2 signal. Or as if whatever it's sending to stderr is not actually
> getting to the filesystem...
>
> In any case, we don't see anything.
Can you check if the signal is received in the master via truss/dtruss?
Do other signals (USR1, HUP, QUIT) work?
You might need to enable the equivalent of "-f" for strace (follow child
processes/threads) since Ruby 1.9 uses a dedicated thread for receiving
signals.
> Any further ideas for how to debug would be much appreciated, and my
> apologies in advance for mixing up any details; Philipp was doing the work
> on this, not me.
Also, which version of Ruby are you using? I'm pretty familiar
with the 1.9.3 implementation, the earlier 1.9.x releases were
messier and noisy wrt signal handling.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* FreeBSD jail and unicorn
@ 2012-01-31 17:22 4% Philipp Bruell
0 siblings, 0 replies; 200+ results
From: Philipp Bruell @ 2012-01-31 17:22 UTC (permalink / raw)
To: mongrel-unicorn@rubyforge.org; +Cc: Charles Hornberger
Hello,
I'm using unicorn since a while, but now I try to run it the first time
inside a FreeBSD jail.
The initial start of unicorn works fine and it serves all the requests.
But if I want to restart it using the USR2 signal, it (more or less)
slowly starts using more and more CPU cycles. There is no error message in
the logs and it quite hard to reproduce that error. In 1 of 20 tries,
unicorn restarts correctly, but in the other cases I have to "kill -9" the
process. I haven't found anything that gives some indication.
I've tried unicorn version 4.1.1 and 4.2.0. The FreeBSD version is
8.2-STABLE amd64.
That my config:
---
listen "/home/deploy/staging/unicorn.sock"
pid "/home/deploy/staging/unicorn.pid"
preload_app true
stderr_path "/home/deploy/staging/unicorn.stderr.log"
stdout_path "/home/deploy/staging/unicorn.stdout.log"
before_fork do |server, worker|
old_pid = "#{server.config[:pid]}.oldbin"
if old_pid != server.pid
begin
process_id = File.read(old_pid).to_i
puts "sending QUIT to #{process_id}"
Process.kill :QUIT, process_id
rescue Errno::ENOENT, Errno::ESRCH
end
end
end
---
I've tried without the before_fork-block, but I think, that's not the
critical part, since it doesn't reach to point where two master processes
exists. There is just the old master consuming all the CPU cycles.
Does someone ran into the same problem? Does someone has an idea?
Thanks in advance
Philipp
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 4%]
* oldest version of Ruby worth supporting?
@ 2012-01-08 4:00 6% Eric Wong
2012-01-08 4:02 6% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2012-01-08 4:00 UTC (permalink / raw)
To: mongrel-unicorn
Do you guys (or know of any users) stuck on Ruby 1.8.5 or earlier?
I know some users on RHEL/CentOS 5 have 1.8.5 installed as /usr/bin/ruby
by default and RHEL/CentOS 5.x will continue to be deployed for many
years to come. This is the unfortunate reality of distributions with
long-term support (and Ruby being a rapidly evolving ecosystem).
Feel free to email me privately, too, running old versions could
be risky and admitting to it could open you up to security issues
(or at least embarrassment :))
Fwiw, I know (and help ensure) Ruby 1.9.3 builds/runs well on
CentOS 5.x. And anybody (on *nix) capable of _running_ Ruby 1.8.x
should have little trouble building the latest 1.9.3 tarball.
This isn't a project which targets 20 year-old i486 systems, so
upgrading the distro/compiler is extremely time-consuming and
nearly impossible for some folks.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 6%]
* Re: oldest version of Ruby worth supporting?
2012-01-08 4:00 6% oldest version of Ruby worth supporting? Eric Wong
@ 2012-01-08 4:02 6% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2012-01-08 4:02 UTC (permalink / raw)
To: mongrel-unicorn
Eric Wong <normalperson@yhbt.net> wrote:
> This isn't a project which targets 20 year-old i486 systems, so
s/, so/, where/
> upgrading the distro/compiler is extremely time-consuming and
> nearly impossible for some folks.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 6%]
* Re: Should USR2 always work?
2011-11-22 3:00 0% ` Eric Wong
@ 2011-11-23 5:31 4% ` Lawrence Pit
0 siblings, 0 replies; 200+ results
From: Lawrence Pit @ 2011-11-23 5:31 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
> I brought up a "bring-your-own-executable" deployment a few months ago
> but haven't heard any feedback. Here it is for Bundler:
>
> http://mid.gmane.org/20110819022316.GA2951@dcvr.yhbt.net
I tried this out by going back to a previous version of bundler, then deployed, unfortunately doesn't seem to work for me:
executing ["/srv/ec/current/script/unicorn_byoe", "-D", "-E", "staging", "-c", "/srv/ec/current/config/unicorn/staging.rb"] (in /srv/ec/releases/20111123052840)
/opt/ree/bin/ruby: no such file to load -- bundler/setup (LoadError)
Sending QUIT and then start anew works fine. Upgraded back to latest, tried again, and again no luck. QUIT + start is the only thing that works then.
Tried a slightly modified version of unicorn_byoe, I'm using rails:
#!/opt/ree/bin/ruby
require File.expand_path("../../config/boot.rb", __FILE__)
# Gem.bin_path(gem_name, executable_name, *version_requirements)
load Gem.bin_path("unicorn", "unicorn_rails")
Cheers,
Lawrence
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 4%]
* Re: Should USR2 always work?
2011-11-22 1:55 3% ` Lawrence Pit
@ 2011-11-22 3:00 0% ` Eric Wong
2011-11-23 5:31 4% ` Lawrence Pit
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2011-11-22 3:00 UTC (permalink / raw)
To: unicorn list; +Cc: Lawrence Pit
Lawrence Pit <lawrence.pit@gmail.com> wrote:
> Bundler has been updated several times this year, I guess every time
> that happens and a new version gets installed a complete restart of
> unicorn is required? Am I the only one seeing this?
Managing bunder has always been tricky, unfortunately.
> Perhaps I'm managing bundler wrong? Bundler and rake are the only two
> gems I install in the global gem space. With an update of bundler I do
> "gem uninstall bundler ; gem bundler install". Should I manage this
> differently?
I brought up a "bring-your-own-executable" deployment a few months ago
but haven't heard any feedback. Here it is for Bundler:
http://mid.gmane.org/20110819022316.GA2951@dcvr.yhbt.net
I am also using something very similar with Isolate:
------------- /full/path/to/app_root/script/unicorn-byoe ---------
#!/home/ew/ruby-1.9.3/bin/ruby
# Unicorn: bring-your-own executable
require "isolate/now"
$LOAD_PATH << "./lib"
load Gem.bin_path("unicorn", "unicorn")
------------------------------- 8< -------------------------------
I run the path using the full pathname, so there's less ambiguity as to
what gets captured as $0 and executed on USR2.
I don't know of anybody else doing/trying this, though.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Should USR2 always work?
@ 2011-11-22 1:55 3% ` Lawrence Pit
2011-11-22 3:00 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Lawrence Pit @ 2011-11-22 1:55 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
> Anything from stderr log files? USR2 will fail if there's
Right:
> ruby: no such file to load -- bundler/setup (LoadError)
> * unicorn/unicorn_rails executable script is missing
> (maybe Bundler is moving it?)
Bundler has been updated several times this year, I guess every time that happens and a new version gets installed a complete restart of unicorn is required? Am I the only one seeing this?
Perhaps I'm managing bundler wrong? Bundler and rake are the only two gems I install in the global gem space. With an update of bundler I do "gem uninstall bundler ; gem bundler install". Should I manage this differently?
Cheers,
Lawrence
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Fix hang when running tests on OpenBSD by skipping two tests
2011-11-14 23:46 2% ` Jeremy Evans
@ 2011-11-15 3:17 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2011-11-15 3:17 UTC (permalink / raw)
To: unicorn list
Jeremy Evans <jeremyevans0@gmail.com> wrote:
> On Mon, Nov 14, 2011 at 9:54 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > Jeremy Evans <jeremyevans0@gmail.com> wrote:
> >> This is obviously not a permanent fix, but I'm not sure why the tests
> >> are hanging, and hanging during a test is bad. I suppose you could
> >> also use a timeout, so the test fails instead of hangs. I'll be happy
> >> to test other patches to either the test suite or the library code
> >> (assuming the hang is fixable on OpenBSD).
> >
> > I'd like to investigate why this fails.
>
> Makes sense. Is there something I can do to help debug?
I normally use "set -x" (using the "V=2" env for gmake should enable it)
or strace (or whatever the OpenBSD equivalent is).
Syscall tracers are *much* easier to follow under MRI 1.9.3 than 1.9.2
due to the timer-thread being non-polling. I always use "-f" to strace
nowadays to follow process/thread creations.
> > So everything under t/ (gmake test-integration) works, too?
> > I much prefer shell-based the test suite myself
>
> I didn't even know about that test suite till now. :)
>
> I started running those tests on OpenBSD. With the way the test suite
> is currently setup, it's a bit of a pain to debug, as it stops at the
> first error. So I have to:
I usually prefer to work on each problem, one-at-a-time. However,
GNU make already has a handy -k/--keep-going flag to ignore failures.
I also use "set -e" in all my shell scripts to catch errors early on.
> ruby 1.9.3 has a couple regular test failures (skipping the two hangs
> with the earlier patch):
>
> : 1) Error:
> : test_parse_error(HttpParserTest):
> : RuntimeError: can't set length of shared string
> : test/unit/test_http_parser.rb:350:in `headers'
> : test/unit/test_http_parser.rb:350:in `test_parse_error'
That's odd, is this with the latest version? (4.1.1)
I thought I fixed all of those issues several months ago...
> : 1) Failure:
> : test_help(ExecTest) [test/exec/test_exec.rb:319]:
> : <0> expected but was
> : <158>.
Can you dump out "test_stderr.#$$.log" just before that assertion?
Thanks!
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Fix hang when running tests on OpenBSD by skipping two tests
@ 2011-11-14 23:46 2% ` Jeremy Evans
2011-11-15 3:17 3% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Jeremy Evans @ 2011-11-14 23:46 UTC (permalink / raw)
To: unicorn list
On Mon, Nov 14, 2011 at 9:54 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Jeremy Evans <jeremyevans0@gmail.com> wrote:
>> This is obviously not a permanent fix, but I'm not sure why the tests
>> are hanging, and hanging during a test is bad. I suppose you could
>> also use a timeout, so the test fails instead of hangs. I'll be happy
>> to test other patches to either the test suite or the library code
>> (assuming the hang is fixable on OpenBSD).
>
> I'd like to investigate why this fails.
Makes sense. Is there something I can do to help debug?
> So everything under t/ (gmake test-integration) works, too?
> I much prefer shell-based the test suite myself
I didn't even know about that test suite till now. :)
I started running those tests on OpenBSD. With the way the test suite
is currently setup, it's a bit of a pain to debug, as it stops at the
first error. So I have to:
1) run the entire test suite
2) wait for it to halt/fail
3) skip the test that halts/fails
4) go to step 1
With some small changes, you can make it through the entire test suite
even if there are errors. It would greatly speed up the debugging
process, but it does require you read the logged output. See the
patch below. With it, I determined the following integration tests
hang/fail:
ruby 1.8.7 and ruby 1.9.3 integration test failures:
t0011-active-unix-socket.sh
# fails: not ok 11 - no errors
t0100-rack-input-tests.sh
# hangs: requires kill to unicorn and kill -9 to sh in the 2nd test
ruby 1.9.3 has a couple regular test failures (skipping the two hangs
with the earlier patch):
: 1) Error:
: test_parse_error(HttpParserTest):
: RuntimeError: can't set length of shared string
: test/unit/test_http_parser.rb:350:in `headers'
: test/unit/test_http_parser.rb:350:in `test_parse_error'
: 1) Failure:
: test_help(ExecTest) [test/exec/test_exec.rb:319]:
: <0> expected but was
: <158>.
Thanks,
Jeremy
$OpenBSD$
--- GNUmakefile.orig Tue Nov 15 00:12:58 2011
+++ GNUmakefile Tue Nov 15 00:13:32 2011
@@ -124,14 +124,14 @@ run_test = $(quiet_pre) \
%.n: export PATH := $(test_prefix)/bin:$(PATH)
%.n: export RUBYLIB := $(test_prefix):$(test_prefix)/lib:$(MYLIBS)
%.n: $(test_prefix)/.stamp
- $(run_test)
+ -$(run_test)
$(T): arg = $@
$(T): t = $(subst .rb,$(log_suffix),$@)
$(T): export PATH := $(test_prefix)/bin:$(PATH)
$(T): export RUBYLIB := $(test_prefix):$(test_prefix)/lib:$(MYLIBS)
$(T): $(test_prefix)/.stamp
- $(run_test)
+ -$(run_test)
install: $(bins) $(ext)/unicorn_http.c
$(prep_setup_rb)
@@ -221,7 +221,7 @@ $(T_r).%.r: export RUBYLIB := $(test_prefix):$(test_pr
$(T_r).%.r: export UNICORN_RAILS_TEST_VERSION = $(rv)
$(T_r).%.r: export RAILS_GIT_REPO = $(CURDIR)/$(rails_git)
$(T_r).%.r: $(test_prefix)/.stamp $(rails_git)/info/v2.2.3-stamp
- $(run_test)
+ -$(run_test)
ifneq ($(VERSION),)
rfproject := mongrel
--- t/GNUmakefile.orig Tue Nov 15 00:12:39 2011
+++ t/GNUmakefile Tue Nov 15 00:12:50 2011
@@ -66,7 +66,7 @@ $(T): export RAKE := $(RAKE)
$(T): export PATH := $(test_prefix)/bin:$(PATH)
$(T): export RUBYLIB := $(test_prefix)/lib:$(MYLIBS)
$(T): dep $(test_prefix)/.stamp trash/.gitignore
- $(TRACER) $(SHELL) $(SH_TEST_OPTS) $@ $(TEST_OPTS)
+ -$(TRACER) $(SHELL) $(SH_TEST_OPTS) $@ $(TEST_OPTS)
trash/.gitignore:
mkdir -p $(@D)
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Sending ABRT to timeout-errant process before KILL
@ 2011-09-08 9:04 2% J. Austin Hughey
0 siblings, 0 replies; 200+ results
From: J. Austin Hughey @ 2011-09-08 9:04 UTC (permalink / raw)
To: mongrel-unicorn
Hello there -
I've recently been working with a customer in my capacity as a support engineer at Engine Yard who's having some trouble with Unicorn. Basically, they're finding their application being force-killed once it reaches the default timeout. Rather than simply increasing the timeout, we're trying to find out _why_ their application is being killed. Unfortunately we can't quite do that because the application is being force-killed without warning, making it so that the customer's logging can't actually be written to the disk. (This is an intermittent issue as opposed to something that happens 100% of the time.)
In discussing the matter internally and with our customer, I came up with a simple monkey patch to Unicorn that _sort of_ works, but I'm having some trouble with it once the number of Unicorn workers goes beyond one. I originally limited it to just one worker because I wanted to limit the possibility that multiple workers could cause problems in figuring things out -- turns out I was right.
I'm going to show the patch in two ways: 1) inline, at the bottom of this post, and 2) by link to GitHub:
https://github.com/jaustinhughey/unicorn/blob/abort_prior_to_kill_workers/lib/unicorn/http_server.rb#L438
The general idea is that I'd like to have some way to "warn" the application when it's about to be killed. I've patched murder_lazy_workers to send an abort signal via kill_worker, sleep for 5 seconds, then look and see if the process still exists by using Process.getpgid. If so, it sends the original kill command, and if not, a rescue block kicks in to prevent the raised error from Process.getpgid from making things explode.
I've created a simulation app, built on Rails 3.0, that uses a generic "posts" controller to simulate a long-running request. Instead of just throwing a straight-up sleep 65 in there, I have it running through sleeping 1 second on a decrementing counter, and doing that 65 times. The reason is because, assuming I've read the code correctly, even with my "skip sleeping workers" commented line below, it'll skip over the process, thus rendering my simulation of a long-running process invalid. However, clarification on this point is certainly welcome. You can see the app here: https://github.com/jaustinhughey/unicorn_test/blob/master/app/controllers/posts_controller.rb
The problem I'm running into, and where I could use some help, is when I increase the number of Unicorn workers from one to two. When running only one Unicorn worker, I can access my application's posts_controller's index action, which has the intentionally long-running code. At that time I tail -f unicorn.log and production.log. Those two logs look like this with one Unicorn worker:
WITH ONE UNICORN WORKER:
========================
production.log:
---------------
Sleeping 1 second (65 to go)…
... continued ...
Sleeping 1 second (7 to go)...
Sleeping 1 second (6 to go)...
Sleeping 1 second (5 to go)...
Caught Unicorn kill exception!
Sleeping 1 second (4 to go)...
Sleeping 1 second (3 to go)...
Sleeping 1 second (2 to go)...
Sleeping 1 second (1 to go)...
Completed 500 Internal Server Error in 65131ms
NoMethodError (undefined method `query_options' for nil:NilClass):
app/controllers/posts_controller.rb:32:in `index'
(I think the NoMethodError issue above is due to me calling a disconnect on ActiveRecord in the Signal.trap block, so I think that can be safely ignored.)
As you can see, the Signal.trap block inside the aforementioned posts_controller is working in this case. Corresponding log entries in unicorn.log concur:
unicorn.log:
------------
worker=0 ready
master process ready
[2011-09-08 00:31:01 PDT] worker=0 PID: 28921 timeout hit, sending ABRT to process 28921 then sleeping 5 seconds...
[2011-09-08 00:31:06 PDT] worker=0 PID:28921 timeout (61s > 60s), killing
reaped #<Process::Status: pid 28921 SIGKILL (signal 9)> worker=0
worker=0 ready
So with one worker, everything seems cool. But with two workers?
WITH TWO UNICORN WORKERS:
=========================
production.log:
---------------
Sleeping 1 second (8 to go)...
Sleeping 1 second (7 to go)...
Sleeping 1 second (6 to go)...
Sleeping 1 second (5 to go)...
Sleeping 1 second (4 to go)...
Sleeping 1 second (3 to go)...
Sleeping 1 second (2 to go)...
Sleeping 1 second (1 to go)...
Rendered posts/index.html.erb within layouts/application (13.2ms)
Completed 200 OK in 65311ms (Views: 16.9ms | ActiveRecord: 0.5ms)
Note that there is no notice that the ABRT signal was trapped, nor is there a NoMethodError (likely caused by disconnecting from the database) as above. Odd.
unicorn.log:
------------
Nothing. No new data whatsoever.
The only potential clue I can see at this point would be a start-up message in unicorn.log. After increasing the number of Unicorn workers to two, I examined unicorn.log again and found this:
master complete
I, [2011-09-08T00:34:40.499437 #29572] INFO -- : unlinking existing socket=/var/run/engineyard/unicorn_ut.sock
I, [2011-09-08T00:34:40.499888 #29572] INFO -- : listening on addr=/var/run/engineyard/unicorn_ut.sock fd=5
I, [2011-09-08T00:34:40.504542 #29572] INFO -- : Refreshing Gem list
worker=0 ready
master process ready
[2011-09-08 00:34:49 PDT] worker=1 PID: 29582 timeout hit, sending ABRT to process 29582 then sleeping 5 seconds...
[2011-09-08 00:34:50 PDT] worker=1 PID:29582 timeout (1315467289s > 60s), killing
reaped #<Process::Status: pid 29582 SIGIOT (signal 6)> worker=1
worker=1 ready
So it looks like Worker 1 is hitting a strange/false timeout of 1315467289 seconds, which isn't really possible as it wasn't even running 1315467289 seconds prior to that (which equates to roughly 41 years ago if my math is right).
---
Needless to say, I'm a bit stumped at this point, and would sincerely appreciate another point of view on this. Am I going about this all wrong? Is there a better approach I should consider? And if I'm on the right track, how can I get this to work regardless of how many Unicorn workers are running?
Thank you very much for any assistance you can provide!
-- INLINE VERSION OF PATCH --
diff --git a/lib/unicorn/http_server.rb b/lib/unicorn/http_server.rb
index 78d80b4..8a2323f 100644
--- a/lib/unicorn/http_server.rb
+++ b/lib/unicorn/http_server.rb
@@ -429,6 +429,11 @@ class Unicorn::HttpServer
proc_name 'master (old)'
end
+ # A custom formatted timestamp for debugging
+ def custom_timestamp
+ return Time.now.strftime("[%Y-%m-%d %T %Z]")
+ end
+
# forcibly terminate all workers that haven't checked in in timeout seconds. The timeout is implemented using an unlinked File
def murder_lazy_workers
t = @timeout
@@ -436,16 +441,40 @@ class Unicorn::HttpServer
now = Time.now.to_i
WORKERS.dup.each_pair do |wpid, worker|
tick = worker.tick
- 0 == tick and next # skip workers that are sleeping
+
+ # REMOVE THE FOLLOWING COMMENT WHEN TESTING PRODUCTION
+# 0 == tick and next # skip workers that are sleeping
+ # ^ needs to be active, commented here for simulation purposes
+
diff = now - tick
tmp = t - diff
if tmp >= 0
next_sleep < tmp and next_sleep = tmp
next
end
- logger.error "worker=#{worker.nr} PID:#{wpid} timeout " \
- "(#{diff}s > #{t}s), killing"
- kill_worker(:KILL, wpid) # take no prisoners for timeout violations
+
+
+ # Send an ABRT signal to Unicorn and wait 5 seconds before attempting an
+ # actual kill, if and only if the process is still running.
+
+ begin
+ # Send the ABRT signal.
+ logger.debug "#{custom_timestamp} worker=#{worker.nr} PID: #{wpid} timeout hit, sending ABRT to process #{wpid} then sleeping 5 seconds..."
+ kill_worker(:ABRT, wpid)
+
+ sleep 5
+
+ # Now see if the process still exists after being given five
+ # seconds to terminate on its own, and if so, do a hard kill.
+ if Process.getpgid(wpid)
+ logger.error "#{custom_timestamp} worker=#{worker.nr} PID:#{wpid} timeout " \
+ "(#{diff}s > #{@timeout}s), killing"
+ kill_worker(:KILL, wpid) # take no prisoners for timeout violations
+ end
+ rescue Errno::ESRCH => e
+ # No process identified - maybe it exited on its own?
+ logger.debug "#{custom_timestamp} worker=#{worker.nr} PID: #{wpid} responded to ABRT on its own and no longer exists. (Received message: #{e})"
+ end
end
next_sleep
end
-- END INLINE VERSION OF PATCH --
--
J. Austin Hughey
Application Support Engineer - Engine Yard
www.engineyard.com | jhughey@engineyard.com
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 2%]
* Re: Strange quit behavior
2011-08-18 23:13 2% ` Alex Sharp
@ 2011-08-19 1:53 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2011-08-19 1:53 UTC (permalink / raw)
To: unicorn list
Alex Sharp <ajsharp@gmail.com> wrote:
> Ok, thanks a lot for the for the patch attempt and subsequent in-depth
> explanation. I know this thread is long-lived and a bit confusing,
> mostly because I've seen two different sets of scenarios that yield
> the same result, which is that unicorn does not restart.
No problem, I'm here to help and mutt makes it easy to follow long threads :>
<snip>
> I thought that setting the Unicorn::HttpServer::START_CTX[0] in my
> unicorn config had solved the first scenario (pegged cpu), but I found
> a new occurrence of it today, and I now have some new strace output
> for this scenario (strace -v):
>
> select(4, [3], NULL, NULL, {60, 727229}) = 0 (Timeout)
> wait4(-1, 0x7ffffd70f72c, WNOHANG, NULL) = 0
> clock_gettime(CLOCK_REALTIME, {1313708081, 720757662}) = 0
> fstat(8, {st_dev=makedev(202, 1), st_ino=39806, st_mode=S_IFREG,
> st_nlink=0, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=0,
> st_size=0, st_atime=2011/08/18-14:32:10, st_mtime=2011/08/18-14:32:10,
> st_ctime=2011/08/18-22:54:06}) = 0
> clock_gettime(CLOCK_REALTIME, {1313708081, 721131305}) = 0
> fstat(10, {st_dev=makedev(202, 1), st_ino=45370, st_mode=S_IFREG,
> st_nlink=0, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=0,
> st_size=0, st_atime=2011/08/18-14:32:10, st_mtime=2011/08/18-14:32:10,
> st_ctime=2011/08/18-22:54:05}) = 0
> clock_gettime(CLOCK_REALTIME, {1313708081, 721290800}) = 0
> select(4, [3], NULL, NULL, {565, 34005}) = 0 (Timeout)
<snip> OK, this looks good from the system call level in the main
thread of the master process:
I can see that from select() timing out despite being called with
long intervals. I don't see workers dying, either...
Can you add "-f -e '!futex'" to the strace invocation so we see
all the threads? You can also add '-T' to get timing information
to see how long each syscall takes or '-tt' to get timestamps
in strace if you think it's useful.
Since the main thread doesn't appear to be doing much, it's
probably a child thread somewhere...
Also, I assume you're using preload_app? If you are, do you see this
issue with preload_app=false? I suspect there's some background thread
that could be running in the master process taking up all the CPU time.
Unicorn itself never spawns background threads.
Basically anything you can tell use about the app, the configuration,
and which gems/libraries would be useful.
> With respect to the second scenario (ignoring signals), I'm going to
> recommend we table that issue for now, as we're currently running on a
> version of ubuntu (11.10) which has a known signal trapping bug with
> ruby 1.9.2-p180, and downgrading to 10.04 may solve that problem.
> Granted, when I've observed this in the past with other libraries, the
> process becomes completely unresponsive, whereas the behavior in
> unicorn is more intermittent. Either way, we are in the process of
> downgrading our servers to ubuntu 10.04, so let's not waste anymore
> time trying to debug something that may well be occurring due to a
> kernel bug. If we continue to see this after the downgrade to 10.04,
> I'll report back and we can keep digging.
OK. I wouldn't rule out the CPU usage as unrelated to the signaling
issue, though. The Ruby 1.9 timer thread could be going crazy
because it can't signal or receive signals properly...
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Strange quit behavior
@ 2011-08-18 23:13 2% ` Alex Sharp
2011-08-19 1:53 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Alex Sharp @ 2011-08-18 23:13 UTC (permalink / raw)
To: unicorn list
Ok, thanks a lot for the for the patch attempt and subsequent in-depth
explanation. I know this thread is long-lived and a bit confusing,
mostly because I've seen two different sets of scenarios that yield
the same result, which is that unicorn does not restart.
The first scenario (and the one that started this thread) was that
unicorn actually receives the signal, spawns a new master, and that
process pegs the cpu and spins into eternity. The second scenario is
that the old master seems to completely ignore the USR2 signal the
first time, and when sent again, properly restarts. In both scenarios
the old master and workers continue to serve the old code.
I thought that setting the Unicorn::HttpServer::START_CTX[0] in my
unicorn config had solved the first scenario (pegged cpu), but I found
a new occurrence of it today, and I now have some new strace output
for this scenario (strace -v):
select(4, [3], NULL, NULL, {60, 727229}) = 0 (Timeout)
wait4(-1, 0x7ffffd70f72c, WNOHANG, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1313708081, 720757662}) = 0
fstat(8, {st_dev=makedev(202, 1), st_ino=39806, st_mode=S_IFREG,
st_nlink=0, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=0,
st_size=0, st_atime=2011/08/18-14:32:10, st_mtime=2011/08/18-14:32:10,
st_ctime=2011/08/18-22:54:06}) = 0
clock_gettime(CLOCK_REALTIME, {1313708081, 721131305}) = 0
fstat(10, {st_dev=makedev(202, 1), st_ino=45370, st_mode=S_IFREG,
st_nlink=0, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=0,
st_size=0, st_atime=2011/08/18-14:32:10, st_mtime=2011/08/18-14:32:10,
st_ctime=2011/08/18-22:54:05}) = 0
clock_gettime(CLOCK_REALTIME, {1313708081, 721290800}) = 0
select(4, [3], NULL, NULL, {565, 34005}) = 0 (Timeout)
wait4(-1, 0x7ffffd70f72c, WNOHANG, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1313708646, 853870540}) = 0
fstat(8, {st_dev=makedev(202, 1), st_ino=39806, st_mode=S_IFREG,
st_nlink=0, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=0,
st_size=0, st_atime=2011/08/18-14:32:10, st_mtime=2011/08/18-14:32:10,
st_ctime=2011/08/18-22:59:06}) = 0
clock_gettime(CLOCK_REALTIME, {1313708646, 854102750}) = 0
fstat(10, {st_dev=makedev(202, 1), st_ino=45370, st_mode=S_IFREG,
st_nlink=0, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=0,
st_size=0, st_atime=2011/08/18-14:32:10, st_mtime=2011/08/18-14:32:10,
st_ctime=2011/08/18-23:04:05}) = 0
clock_gettime(CLOCK_REALTIME, {1313708646, 854260655}) = 0
select(4, [3], NULL, NULL, {598, 630876}
With respect to the second scenario (ignoring signals), I'm going to
recommend we table that issue for now, as we're currently running on a
version of ubuntu (11.10) which has a known signal trapping bug with
ruby 1.9.2-p180, and downgrading to 10.04 may solve that problem.
Granted, when I've observed this in the past with other libraries, the
process becomes completely unresponsive, whereas the behavior in
unicorn is more intermittent. Either way, we are in the process of
downgrading our servers to ubuntu 10.04, so let's not waste anymore
time trying to debug something that may well be occurring due to a
kernel bug. If we continue to see this after the downgrade to 10.04,
I'll report back and we can keep digging.
Again, my apologies for the confusion between the two scenarios, and
thanks for all your help.
- Alex
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: Strange quit behavior
2011-08-05 8:07 3% ` Eric Wong
@ 2011-08-17 4:26 3% ` Alex Sharp
0 siblings, 1 reply; 200+ results
From: Alex Sharp @ 2011-08-17 4:26 UTC (permalink / raw)
To: unicorn list
On Fri, Aug 5, 2011 at 1:07 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Is this Unicorn 3.x? Which 3.x version exactly? Maybe give 4.0.1
> or the 4.0.2 git prerelease a try, too.
We're using version 3.6.2 with ruby 1.9.2-p180 on ubuntu 11.x. I know
the kernel on this version of ubuntu has a know signal trapping bug,
but I don't think that's what happening here. The processes respond
after I send the restart signal to them again (USR2 + QUIT).
> Can I get more? (until the next select() call, at least). I'd like to
> see the timeout argument that gets passed to the next select().
Here's some more output. This is from the old master though, not a new
master that is pegging the CPU. In this instance it's almost like the
old master just ignores the signal.
select(4, [3], NULL, NULL, {8, 129984}) = 0 (Timeout)
wait4(-1, 0x7fff16b82e4c, WNOHANG, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1313554942, 259408364}) = 0
fstat(12, {st_dev=makedev(202, 1), st_ino=20373, st_mode=S_IFREG,
st_nlink=0, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=0,
st_size=0, st_atime=2011/08/12-23:14:20, st_mtime=2011/08/12-23:14:20,
st_ctime=2011/08/17-04:22:21}) = 0
clock_gettime(CLOCK_REALTIME, {1313554942, 259775504}) = 0
fstat(13, {st_dev=makedev(202, 1), st_ino=20381, st_mode=S_IFREG,
st_nlink=0, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=0,
st_size=0, st_atime=2011/08/12-23:14:20, st_mtime=2011/08/12-23:14:20,
st_ctime=2011/08/17-04:22:17}) = 0
clock_gettime(CLOCK_REALTIME, {1313554942, 259936816}) = 0
fstat(14, {st_dev=makedev(202, 1), st_ino=20382, st_mode=S_IFREG,
st_nlink=0, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=0,
st_size=0, st_atime=2011/08/12-23:14:21, st_mtime=2011/08/12-23:14:21,
st_ctime=2011/08/17-04:22:19}) = 0
clock_gettime(CLOCK_REALTIME, {1313554942, 260086380}) = 0
fstat(15, {st_dev=makedev(202, 1), st_ino=20185, st_mode=S_IFREG,
st_nlink=0, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=0,
st_size=0, st_atime=2011/08/12-23:14:21, st_mtime=2011/08/12-23:14:21,
st_ctime=2011/08/17-04:22:17}) = 0
clock_gettime(CLOCK_REALTIME, {1313554942, 260235797}) = 0
fstat(16, {st_dev=makedev(202, 1), st_ino=20255, st_mode=S_IFREG,
st_nlink=0, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=0,
st_size=0, st_atime=2011/08/12-23:14:21, st_mtime=2011/08/12-23:14:21,
st_ctime=2011/08/17-04:22:19}) = 0
clock_gettime(CLOCK_REALTIME, {1313554942, 260384849}) = 0
fstat(17, {st_dev=makedev(202, 1), st_ino=20383, st_mode=S_IFREG,
st_nlink=0, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=0,
st_size=0, st_atime=2011/08/12-23:14:21, st_mtime=2011/08/12-23:14:21,
st_ctime=2011/08/17-04:22:19}) = 0
clock_gettime(CLOCK_REALTIME, {1313554942, 260534792}) = 0
fstat(18, {st_dev=makedev(202, 1), st_ino=20384, st_mode=S_IFREG,
st_nlink=0, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=0,
st_size=0, st_atime=2011/08/12-23:14:21, st_mtime=2011/08/12-23:14:21,
st_ctime=2011/08/17-04:22:19}) = 0
clock_gettime(CLOCK_REALTIME, {1313554942, 260684278}) = 0
fstat(10, {st_dev=makedev(202, 1), st_ino=20196, st_mode=S_IFREG,
st_nlink=0, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=0,
st_size=0, st_atime=2011/08/16-16:33:46, st_mtime=2011/08/16-16:33:46,
st_ctime=2011/08/17-04:22:19}) = 0
clock_gettime(CLOCK_REALTIME, {1313554942, 260833725}) = 0
select(4, [3], NULL, NULL, {8, 976047}
> If you see select() with very small timeout, use "strace -v" to get the
> st_ctime from fstat()s...
>
> I could have a math bug in murder_lazy_workers (please read/review the
> logic in that method, I haven't noticed issues myself).
>
> I made some tweaks to the master sleep strategy within the past year to
> reduce wakeups during idle hours. This is intended to go with Ruby
> 1.9.3 which will have /much/ better thread wakeup strategy that reduces
> power consumption during idle times.
>
>> The first line was when the master was idle, and then I threw a few
>> requests at it.
>
> Are all workers responding as expected and not dying?
The old workers appear to be serving requests.
- Alex
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Strange quit behavior
@ 2011-08-05 8:07 3% ` Eric Wong
2011-08-17 4:26 3% ` Alex Sharp
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2011-08-05 8:07 UTC (permalink / raw)
To: unicorn list
Alex Sharp <ajsharp@gmail.com> wrote:
> On Thu, Aug 4, 2011 at 9:09 PM, Alex Sharp <ajsharp@gmail.com> wrote:
> > On Tue, Aug 2, 2011 at 2:54 PM, Eric Wong <normalperson@yhbt.net> wrote:
> >> Can you try to strace (or equivalent) the old master to see what's using
> >> 100% CPU?
> >>
>
> Actually, my fault -- the last email was the output of new master.
> Running strace on the old master shows the following:
Is this Unicorn 3.x? Which 3.x version exactly? Maybe give 4.0.1
or the 4.0.2 git prerelease a try, too.
> select(4, [3], NULL, NULL, {13, 466686}) = 0 (Timeout)
> wait4(-1, 0x7fff57e7bfcc, WNOHANG, NULL) = 0
> clock_gettime(CLOCK_REALTIME, {1312517345, 425411398}) = 0
> fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
> clock_gettime(CLOCK_REALTIME, {1312517345, 425625251}) = 0
> fstat(11, {st_mode=S_IFREG, st_size=0, ...}) = 0
> clock_gettime(CLOCK_REALTIME, {1312517345, 425779281}) = 0
> fstat(12, {st_mode=S_IFREG, st_size=0, ...}) = 0
> clock_gettime(CLOCK_REALTIME, {1312517345, 425927762}) = 0
Can I get more? (until the next select() call, at least). I'd like to
see the timeout argument that gets passed to the next select().
If you see select() with very small timeout, use "strace -v" to get the
st_ctime from fstat()s...
I could have a math bug in murder_lazy_workers (please read/review the
logic in that method, I haven't noticed issues myself).
I made some tweaks to the master sleep strategy within the past year to
reduce wakeups during idle hours. This is intended to go with Ruby
1.9.3 which will have /much/ better thread wakeup strategy that reduces
power consumption during idle times.
> The first line was when the master was idle, and then I threw a few
> requests at it.
Are all workers responding as expected and not dying?
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Strange quit behavior
2011-08-02 21:53 3% ` Eric Wong
@ 2011-08-02 22:46 0% ` James Cox
0 siblings, 0 replies; 200+ results
From: James Cox @ 2011-08-02 22:46 UTC (permalink / raw)
To: Eric Wong, unicorn list
On Tue, Aug 2, 2011 at 17:53, Eric Wong <normalperson@yhbt.net> wrote:
> James Cox <james@imaj.es> wrote:
>> Hey,
>>
>> So here are some tasks for managing unicorn:
>>
>> https://gist.github.com/1121076
>
> Can we ignore the :restart task? It's a bit fragile since it doesn't
> wait for the old process to die (SIGTERM means
> kill-as-quickly-as-possible, but given a loaded system it can still take
> some time).
We mostly restart (what surprise). What pattern works best here for
that? (speed of deploy is important, but definitely assume a long boot
time)
>
>> I've found that it's very unreliable for quitting / terminating
>> unicorn and restarting with new code. When doing rapid deployments
>> particularly, i've found that i have to go in and kill -9 the master
>> process, and start again.
>
> If you SIGQUIT/SIGTERM before the app is loaded, the signal could
> be ignored. This behavior should probably change...
>
>> any thoughts on why it seems ineffective?
>>
>> Thanks.
>
> Which version of Unicorn are you using? I recall some minor tweaks
> to avoid/minimize race conditions over the years so maybe some
> are fixed.
>
gem 'unicorn' - so whatever seems up to date. My lock says 4.0.1
>> PS: here's the unicorn config:
>>
>> https://gist.github.com/0dd07c5ad00c56d161c7
>
> Avoid the top piece of the before_fork hook to TTOU workers, it's
> needlessly complex for most deployments unless you're really
> memory-constrained.
>
So what should that look like? all but that nr-workers stuff? can i
just remove the before fork? and what would you say is a super good
unicorn config to start from?
thanks!
james
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Strange quit behavior
@ 2011-08-02 21:53 3% ` Eric Wong
2011-08-02 22:46 0% ` James Cox
1 sibling, 1 reply; 200+ results
From: Eric Wong @ 2011-08-02 21:53 UTC (permalink / raw)
To: unicorn list; +Cc: James Cox
James Cox <james@imaj.es> wrote:
> Hey,
>
> So here are some tasks for managing unicorn:
>
> https://gist.github.com/1121076
Can we ignore the :restart task? It's a bit fragile since it doesn't
wait for the old process to die (SIGTERM means
kill-as-quickly-as-possible, but given a loaded system it can still take
some time).
> I've found that it's very unreliable for quitting / terminating
> unicorn and restarting with new code. When doing rapid deployments
> particularly, i've found that i have to go in and kill -9 the master
> process, and start again.
If you SIGQUIT/SIGTERM before the app is loaded, the signal could
be ignored. This behavior should probably change...
> any thoughts on why it seems ineffective?
>
> Thanks.
Which version of Unicorn are you using? I recall some minor tweaks
to avoid/minimize race conditions over the years so maybe some
are fixed.
> PS: here's the unicorn config:
>
> https://gist.github.com/0dd07c5ad00c56d161c7
Avoid the top piece of the before_fork hook to TTOU workers, it's
needlessly complex for most deployments unless you're really
memory-constrained.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: SIGTERM not actually killing processes
[not found] ` <CAFgS5CxwCmHL65W39R2W73YfUK34WX50DS_JJF4L-d_tQuH86Q@mail.gmail.com>
@ 2011-07-25 23:20 0% ` Jesse Cooke
0 siblings, 0 replies; 200+ results
From: Jesse Cooke @ 2011-07-25 23:20 UTC (permalink / raw)
To: unicorn list
Sending TERM directly to the master process killed it.
--------------------------------------------
Jesse Cooke :: N-tier Engineer
jc00ke.com / @jc00ke
On Mon, Jul 25, 2011 at 3:30 PM, Jesse Cooke <jesse@jc00ke.com> wrote:
>
> Sending TERM directly to the master process killed it.
>
> --------------------------------------------
> Jesse Cooke :: N-tier Engineer
> jc00ke.com / @jc00ke
>
>
> On Mon, Jul 25, 2011 at 2:32 PM, Alex Sharp <ajsharp@gmail.com> wrote:
>>
>> On Monday, July 25, 2011 at 2:22 PM, Eric Wong wrote:
>>
>> Jesse Cooke <jesse@jc00ke.com> wrote:
>>
>> Hi,
>> Unicorn is saying it's terminating but it's not actually. Check out
>> the gist: https://gist.github.com/1104930
>>
>> Using:
>> - Ruby 1.9.2p180
>> - unicorn 4.0.1
>> - kgio 2.6.0
>> - bundler 1.0.15
>> - Linux maynard 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17
>> UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Please let me know if there's any other info I can provide.
>>
>> Since it's a 2.6.38 kernel, I it could be this bug:
>> https://bugzilla.kernel.org/show_bug.cgi?id=32922
>>
>> Linux 2.6.38.4 should have the fix, but I'm not sure if Ubuntu
>> backported that fix to its 2.6.38-10 package.
>>
>> Rubyists have seen this issue a few times already:
>> http://redmine.ruby-lang.org/issues/4777
>> http://redmine.ruby-lang.org/issues/4939
>>
>>
>> Also, can you try sending signals directly to Unicorn without foreman?
>> I'm not familiar with foreman at all, maybe somebody else on this list
>> is...
>>
>> Not familiar with foreman, but I've verified the issues you've linked to with another non-unicorn problem (god, actually). As of a couple of weeks ago, the kernel bug still existed in ubuntu 11.04, and to my knowledge, this is the only affected major version. We're in the process of moving to ubuntu 10.10 (mostly specifically because of this bug), which is the most recent LTS release, and not affected by the signal trapping bug.
>>
>> --
>> Eric Wong
>> _______________________________________________
>> Unicorn mailing list - mongrel-unicorn@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
>> Do not quote signatures (like this one) or top post when replying
>>
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Problems running unicorn_rails without bundle exec (in a RVM context)
2011-07-23 23:03 0% ` Maurizio De Santis
@ 2011-07-24 0:48 0% ` Scott Windsor
0 siblings, 0 replies; 200+ results
From: Scott Windsor @ 2011-07-24 0:48 UTC (permalink / raw)
To: unicorn list
On Sat, Jul 23, 2011 at 4:03 PM, Maurizio De Santis
<desantis.maurizio@gmail.com> wrote:
>> You should use bundle exec if your app is using bundler. Otherwise you
>> can try uninstall the conflicting version of rack from your system/RVM
>> installation, but that defeats the purpose of bundler...
>
> uhm, this will make my life more difficoult because I'm trying to
> write an upstart srcript for unicorn_rails, and so I have to consider
> this too... more work for me :)
>
Have you looked at foreman?
http://blog.daviddollar.org/2011/05/06/introducing-foreman.html
It's a pretty good approach to process management and can export the
upstart scripts for you...
- scott
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Problems running unicorn_rails without bundle exec (in a RVM context)
2011-07-23 20:57 3% ` Eric Wong
@ 2011-07-23 23:03 0% ` Maurizio De Santis
2011-07-24 0:48 0% ` Scott Windsor
0 siblings, 1 reply; 200+ results
From: Maurizio De Santis @ 2011-07-23 23:03 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
> You should use bundle exec if your app is using bundler. Otherwise you
> can try uninstall the conflicting version of rack from your system/RVM
> installation, but that defeats the purpose of bundler...
uhm, this will make my life more difficoult because I'm trying to
write an upstart srcript for unicorn_rails, and so I have to consider
this too... more work for me :)
>> Please add me in the CC replies, I am not subscribed to the newsletter.
>
> Thanks for making a note of this :>
>
I read the ISSUES page carefully before to write :)
Thank you!
--
Maurizio De Santis
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Problems running unicorn_rails without bundle exec (in a RVM context)
@ 2011-07-23 20:57 3% ` Eric Wong
2011-07-23 23:03 0% ` Maurizio De Santis
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2011-07-23 20:57 UTC (permalink / raw)
To: unicorn list; +Cc: Maurizio De Santis
Maurizio De Santis <desantis.maurizio@gmail.com> wrote:
> Hello,
>
> I cannot run unicorn_rails out without using bundle exec . This is the error:
>
> /home/user/.rvm/gems/ruby-1.9.2-p180/gems/bundler-1.0.15/lib/bundler/runtime.rb:31:in
> `block in setup': You have already activated rack 1.3.1, but your
> Gemfile requires rack 1.2.3. Consider using bundle exec.
> (Gem::LoadError)
>
> Maybe RVM is involved? Maybe I am involved?
You should use bundle exec if your app is using bundler. Otherwise you
can try uninstall the conflicting version of rack from your system/RVM
installation, but that defeats the purpose of bundler...
> Please add me in the CC replies, I am not subscribed to the newsletter.
Thanks for making a note of this :>
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Undefined method after switching to unicorn
@ 2011-07-18 19:42 5% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2011-07-18 19:42 UTC (permalink / raw)
To: unicorn list
Douglas André <douglasmoura27@gmail.com> wrote:
> Hello, I'm having the same issue with Unicorn 3.7.0 and rails 3.0.9.
> I don't have any idea what could cause this problem. Please help me!!
Did you try disabling preload_app? If that doesn't help, help us
help you by telling us everything you can about your setup,
including (and not limited to):
* Anything that maintains network connections/open files
* All gems and versions you use, including the versions of 3rd party
libraries (e.g. OpenSSL version)
* OS version
* Ruby version
* CPU architecture
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 5%]
* SQL Server errors when using unicorn
@ 2011-07-08 18:30 2% Marc Sernatinger
0 siblings, 0 replies; 200+ results
From: Marc Sernatinger @ 2011-07-08 18:30 UTC (permalink / raw)
To: mongrel-unicorn
Lately I have been seeing a large volume of database errors in a couple of applications at work. This has proven difficult to troubleshoot: after some restarts of unicorn, things seem fine. Then, a restart as part of a new deployment introduces these issues anew, with rollback to the previous version of the app still producing errors.
One thing I have noticed is in my troubleshooting is that I seem to be able to reproduce these errors only after a period of idleness or low activity on the part of unicorn. Running unicorn on my workstation, running ab with a concurrency of 5 or so is enough to produce the issue reasonably often.
I bring this question to the unicorn discussion because I noticed we don't have this problem using Passenger. I was wondering if there were any particulars of our setup that seem problematic.
Here is an example of the error we see. It is not always exactly this error. Sometimes we will see a bad token error from SQL Server. Other times the error manifests itself in ActiveRecord dynamic methods not being properly created:
[ WARN 11-07-08 11:42:29 25300:0x1001d6360 ] Internal Server Error ODBC::Error: 01000 (20017) [unixODBC][FreeTDS][SQL Server]Unexpected EOF from the server: SELECT columns.TABLE_NAME as table_name, columns.COLUMN_NAME as name, columns.DATA_TYPE as type, columns.COLUMN_DEFAULT as default_value, columns.NUMERIC_SCALE as numeric_scale, columns.NUMERIC_PRECISION as numeric_precision, CASE WHEN columns.DATA_TYPE IN ('nchar','nvarchar') THEN columns.CHARACTER_MAXIMUM_LENGTH ELSE COL_LENGTH(columns.TABLE_SCHEMA+'.'+columns.TABLE_NAME, columns.COLUMN_NAME) END as length, CASE WHEN columns.IS_NULLABLE = 'YES' THEN 1 ELSE NULL END as is_nullable, CASE WHEN COLUMNPROPERTY(OBJECT_ID(columns.TABLE_SCHEMA+'.'+columns.TABLE_NAME), columns.COLUMN_NAME, 'IsIdentity') = 0 THEN NULL ELSE 1 END as is_identit
y FROM INFORMATION_SCHEMA.COLUMNS columns WHERE columns.TABLE_NAME = 'users' AND columns.TABLE_SCHEMA = schema_name() ORDER BY columns.ordinal_position
Our stack:
Rails 3.0.7
activerecord-sqlserver-adapter 3.0.15 using ruby-odbc and FreeTDS 0.82
unicorn 3.5.0 with nginx in front
SQL Server 2005 -- at a different site from our web servers, connected by WAN
CentOS 5.9
I appreciate any suggestions as to where the problem may lie.
Thanks
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: Unicorn completely ignores USR2 signal
@ 2011-07-07 17:52 4% ` Alex Sharp
0 siblings, 0 replies; 200+ results
From: Alex Sharp @ 2011-07-07 17:52 UTC (permalink / raw)
To: unicorn list
Can you report the following? Ruby version (including the patch
number), OS and version? The linux kernel shipped with Ubuntu natty
11.04 has a known bug with signal trapping that affects ruby 1.9.2.
See here:
* https://github.com/bvandenbos/resque-scheduler/issues/90
* https://bugzilla.kernel.org/show_bug.cgi?id=32922
On Thu, Jul 7, 2011 at 4:18 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Any progress on this issue? I'll have limited network access
> the next few days...
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>
--
Best,
alex sharp
github.com/ajsharp
twitter.com/ajsharp
alexjsharp.com
615.243.1472
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 4%]
* Re: [PATCH] replace fchmod()-based heartbeat with raindrops
2011-06-25 0:15 0% ` Eric Wong
@ 2011-06-26 5:36 0% ` Aleksandar Simic
0 siblings, 0 replies; 200+ results
From: Aleksandar Simic @ 2011-06-26 5:36 UTC (permalink / raw)
To: unicorn list
On Sat, Jun 25, 2011 at 1:15 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Aleksandar Simic <asimic@gmail.com> wrote:
>> Hello,
>>
>> the same OS & ruby version as the original poster who reported the
>> issue. I see the same symptoms.
>>
>> Cowboy fix: adding "-D__BSD_VISIBLE" to CPPFLAGS gets raindrops gem to build.
>>
>> Easily accessible and viewable sys/mmap.h:
>>
>> http://www.gitorious.net/freebsd/freebsd/blobs/HEAD/sys/sys/mman.h
>
> Aha! So defining _XOPEN_SOURCE appears to cause __BSD_VISIBLE to
> not be defined in sys/cdefs.h. I've pushed out the below patch to
> git://bogomips.org/raindrops.git
>
>> If required, I can give you access to my FreeBSD machine, just let me know.
>
> If the below patch doesn't fix it, yes, it'd be greatly appreciated,
> thanks!
>
> >From 1e7dc89cc38c5dec0b63ac452b23141297701f88 Mon Sep 17 00:00:00 2001
> From: Eric Wong <normalperson@yhbt.net>
> Date: Fri, 24 Jun 2011 17:06:56 -0700
> Subject: [PATCH] remove _XOPEN_SOURCE #define for FreeBSD
>
> This appears to cause __BSD_VISIBLE to not be defined,
> which is required for MAP_ANON to be visible in
> sys/mman.h
>
> Thanks for Aleksandar Simic for the hint and Troex Nevelin
> for the bug report!
> ---
> ext/raindrops/extconf.rb | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/ext/raindrops/extconf.rb b/ext/raindrops/extconf.rb
> index 825625d..9f5de95 100644
> --- a/ext/raindrops/extconf.rb
> +++ b/ext/raindrops/extconf.rb
> @@ -7,7 +7,7 @@ have_func('munmap', 'sys/mman.h') or abort 'munmap() not found'
> $CPPFLAGS += " -D_GNU_SOURCE "
> have_func('mremap', 'sys/mman.h')
>
> -$CPPFLAGS += " -D_BSD_SOURCE -D_XOPEN_SOURCE=600 "
> +$CPPFLAGS += " -D_BSD_SOURCE "
> have_func("getpagesize", "unistd.h")
> have_func('rb_thread_blocking_region')
> have_func('rb_thread_io_blocking_region')
Hello,
just to report back that this does fix the issue.
Thanks,
Aleksandar
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: [PATCH] replace fchmod()-based heartbeat with raindrops
2011-06-24 22:50 3% ` Aleksandar Simic
@ 2011-06-25 0:15 0% ` Eric Wong
2011-06-26 5:36 0% ` Aleksandar Simic
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2011-06-25 0:15 UTC (permalink / raw)
To: unicorn list
Aleksandar Simic <asimic@gmail.com> wrote:
> Hello,
>
> the same OS & ruby version as the original poster who reported the
> issue. I see the same symptoms.
>
> Cowboy fix: adding "-D__BSD_VISIBLE" to CPPFLAGS gets raindrops gem to build.
>
> Easily accessible and viewable sys/mmap.h:
>
> http://www.gitorious.net/freebsd/freebsd/blobs/HEAD/sys/sys/mman.h
Aha! So defining _XOPEN_SOURCE appears to cause __BSD_VISIBLE to
not be defined in sys/cdefs.h. I've pushed out the below patch to
git://bogomips.org/raindrops.git
> If required, I can give you access to my FreeBSD machine, just let me know.
If the below patch doesn't fix it, yes, it'd be greatly appreciated,
thanks!
>From 1e7dc89cc38c5dec0b63ac452b23141297701f88 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Fri, 24 Jun 2011 17:06:56 -0700
Subject: [PATCH] remove _XOPEN_SOURCE #define for FreeBSD
This appears to cause __BSD_VISIBLE to not be defined,
which is required for MAP_ANON to be visible in
sys/mman.h
Thanks for Aleksandar Simic for the hint and Troex Nevelin
for the bug report!
---
ext/raindrops/extconf.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ext/raindrops/extconf.rb b/ext/raindrops/extconf.rb
index 825625d..9f5de95 100644
--- a/ext/raindrops/extconf.rb
+++ b/ext/raindrops/extconf.rb
@@ -7,7 +7,7 @@ have_func('munmap', 'sys/mman.h') or abort 'munmap() not found'
$CPPFLAGS += " -D_GNU_SOURCE "
have_func('mremap', 'sys/mman.h')
-$CPPFLAGS += " -D_BSD_SOURCE -D_XOPEN_SOURCE=600 "
+$CPPFLAGS += " -D_BSD_SOURCE "
have_func("getpagesize", "unistd.h")
have_func('rb_thread_blocking_region')
have_func('rb_thread_io_blocking_region')
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 0%]
* Re: [PATCH] replace fchmod()-based heartbeat with raindrops
@ 2011-06-24 22:50 3% ` Aleksandar Simic
2011-06-25 0:15 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Aleksandar Simic @ 2011-06-24 22:50 UTC (permalink / raw)
To: unicorn list
On Fri, Jun 24, 2011 at 9:51 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Jeremy Evans <jeremyevans0@gmail.com> wrote:
>> On Fri, Jun 24, 2011 at 10:30 AM, Eric Wong <normalperson@yhbt.net> wrote:
>> > Eric Wong <normalperson@yhbt.net> wrote:
>> >> The subset of raindrops used by Unicorn should work on all machines
>> >> with mmap(2) + MAP_ANON/MAP_ANONYMOUS support, so *BSDs shouldn't be
>> >> left out.
>>
>> FWIW, raindrops builds fine on OpenBSD 4.9 amd64.
>
> Thanks for the confirmation! I'm at a loss as to what's causing
> issues under FreeBSD 8 for him...
Hello,
the same OS & ruby version as the original poster who reported the
issue. I see the same symptoms.
Cowboy fix: adding "-D__BSD_VISIBLE" to CPPFLAGS gets raindrops gem to build.
Easily accessible and viewable sys/mmap.h:
http://www.gitorious.net/freebsd/freebsd/blobs/HEAD/sys/sys/mman.h
If required, I can give you access to my FreeBSD machine, just let me know.
Thanks,
Aleksandar
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: problem setting multiple cookies
2011-06-21 3:38 0% ` Jason Su
@ 2011-06-21 18:29 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2011-06-21 18:29 UTC (permalink / raw)
To: unicorn list
Jason Su <jason@lookbook.nu> wrote:
> I'm using unicorn 3.6.2
>
> What I was trying to say is that the JoinCookie middleware didn't do
> anything. headers["Set-Cookie"] is a string, and the _test_session
> cookie was always being set correctly. The problem happens only when I
> try to set multiple cookies myself.
Yeah, you're not getting an Array (at least not at that stage) as I
semi-hoped so JoinCookie wouldn't solve it.
> Here's the output of p headers in JoinCookie again
>
> {"X-Runtime"=>"92", "Content-Type"=>"text/html",
> "Content-Length"=>"1", "Set-Cookie"=>"first=; domain=.test.com;
> path=/; expires=Thu, 01-Jan-1970 00:00:00 GMTsecond=1;
> domain=.test.com; path=/; expires=Mon, 21-Jun-2021 03:35:30
> GMT\n_test_session=1804126e6bad8cf4b25602b74218f003; domain=.test.com;
> path=/; HttpOnly", "Cache-Control"=>"no-cache"}
>
> Where is JoinCookie is getting it's headers from?
app.call(env) is what dispatches your Rails app, so the headers are what
Rails (and middlewares further down the stack) sets.
Any luck with looking at Rails changes that might impact this?
At this point it's clear it's a Rails/Rack issue (and for an old
version, at that) and not something that can be done with Unicorn.
Maybe you can fix whatever the Rails v2.3.8..v2.3.11 upgrade broke
in your app, but whatever's broken is broken at the application layer
and not in Unicorn.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: problem setting multiple cookies
2011-06-21 3:15 3% ` Eric Wong
@ 2011-06-21 3:38 0% ` Jason Su
2011-06-21 18:29 3% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Jason Su @ 2011-06-21 3:38 UTC (permalink / raw)
To: unicorn list
I'm using unicorn 3.6.2
What I was trying to say is that the JoinCookie middleware didn't do
anything. headers["Set-Cookie"] is a string, and the _test_session
cookie was always being set correctly. The problem happens only when I
try to set multiple cookies myself.
Here's the output of p headers in JoinCookie again
{"X-Runtime"=>"92", "Content-Type"=>"text/html",
"Content-Length"=>"1", "Set-Cookie"=>"first=; domain=.test.com;
path=/; expires=Thu, 01-Jan-1970 00:00:00 GMTsecond=1;
domain=.test.com; path=/; expires=Mon, 21-Jun-2021 03:35:30
GMT\n_test_session=1804126e6bad8cf4b25602b74218f003; domain=.test.com;
path=/; HttpOnly", "Cache-Control"=>"no-cache"}
Where is JoinCookie is getting it's headers from?
On Mon, Jun 20, 2011 at 8:15 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Jason Su <jason@lookbook.nu> wrote:
>> Here's what I get in the response, with the _test_session cookie line:
>>
>> Set-Cookie:first=; domain=.test.com; path=/; expires=Thu, 01-Jan-1970
>> 00:00:00 GMTsecond=1; domain=.test.com; path=/; expires=Mon,
>> 21-Jun-2021 02:40:27 GMT
>> _test_session=40658e37c9e8b39c5f8389e09682c47b; domain=.test.com;
>> path=/; HttpOnly
>>
>> It doesn't add a second Set-Cookie: line, but the line break seems to work...
>
> Huh? Which version of unicorn are you using? The /\n/ splitting in
> headers has been in the earliest releases of unicorn...
>
>> 2.3.11 is giving me a ton of trouble.. I've tried it before.. and I
>> just tried again with little luck... Is there anything that I can just
>> grab from the commits to make it work on 2.3.8?
>
> Look at the individual commits in rails.git. I just used
>
> git log -p v2.3.8..v2.3.11 -- actionpack
>
> in rails.git to find those for you. I just looked for things that
> would manipulate cookies/headers.
>
> --
> Eric Wong
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: problem setting multiple cookies
@ 2011-06-21 3:15 3% ` Eric Wong
2011-06-21 3:38 0% ` Jason Su
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2011-06-21 3:15 UTC (permalink / raw)
To: unicorn list
Jason Su <jason@lookbook.nu> wrote:
> Here's what I get in the response, with the _test_session cookie line:
>
> Set-Cookie:first=; domain=.test.com; path=/; expires=Thu, 01-Jan-1970
> 00:00:00 GMTsecond=1; domain=.test.com; path=/; expires=Mon,
> 21-Jun-2021 02:40:27 GMT
> _test_session=40658e37c9e8b39c5f8389e09682c47b; domain=.test.com;
> path=/; HttpOnly
>
> It doesn't add a second Set-Cookie: line, but the line break seems to work...
Huh? Which version of unicorn are you using? The /\n/ splitting in
headers has been in the earliest releases of unicorn...
> 2.3.11 is giving me a ton of trouble.. I've tried it before.. and I
> just tried again with little luck... Is there anything that I can just
> grab from the commits to make it work on 2.3.8?
Look at the individual commits in rails.git. I just used
git log -p v2.3.8..v2.3.11 -- actionpack
in rails.git to find those for you. I just looked for things that
would manipulate cookies/headers.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: [PATCH] Ensure that 'make gem' builds the documentation too.
@ 2011-06-06 17:51 15% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2011-06-06 17:51 UTC (permalink / raw)
To: unicorn list
Hongli Lai <hongli@phusion.nl> wrote:
> >From bfefc2cf0efb0913a42862886363b3140dcdbb2a Mon Sep 17 00:00:00 2001
> From: Hongli Lai (Phusion) <hongli@phusion.nl>
> Date: Mon, 6 Jun 2011 13:39:00 +0200
> Subject: [PATCH] Ensure that 'make gem' builds the documentation too.
>
> If autogenerated documentation files, like man pages, don't exist then
> 'make gem' will fail, complaining that some files are not found. By
> depending the 'gem' target on the 'doc' target we ensure that 'make gem'
> always works.
>
> Signed-off-by: Hongli Lai (Phusion) <hongli@phusion.nl>
Oops, this was a regression introduced when I switched to wrongdoc
in f62ef19a4aa3d3e4ce1aa37a499907ff776a8964
Perhaps this is better? It'll also affect the tgz target and not
just the gem target.
diff --git a/GNUmakefile b/GNUmakefile
index da55052..61fb739 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -164,7 +164,7 @@ pkg_extra := GIT-VERSION-FILE ChangeLog LATEST NEWS \
ChangeLog: GIT-VERSION-FILE .wrongdoc.yml
wrongdoc prepare
-.manifest: ChangeLog $(ext)/unicorn_http.c
+.manifest: ChangeLog $(ext)/unicorn_http.c man
(git ls-files && for i in $@ $(pkg_extra); do echo $$i; done) | \
LC_ALL=C sort > $@+
cmp $@+ $@ || mv $@+ $@
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 15%]
* Re: unicorn stuck in sched_yield after ERESTARTNOHAND
2011-05-31 15:17 3% ` Eric Wong
@ 2011-05-31 22:28 0% ` Bharanee Rathna
0 siblings, 0 replies; 200+ results
From: Bharanee Rathna @ 2011-05-31 22:28 UTC (permalink / raw)
To: unicorn list
> Can you try 1.9.2-p180 or Ruby trunk? Or maybe a different version of
> glibc, too.
upgraded libc6 & ruby and was able to replicate it under libc6
2.12.1-0ubuntu10.2
$ ruby -v
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux]
> Do you have any non-standard kernel patches/scheduler
> configs?
No
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: unicorn stuck in sched_yield after ERESTARTNOHAND
@ 2011-05-31 15:17 3% ` Eric Wong
2011-05-31 22:28 0% ` Bharanee Rathna
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2011-05-31 15:17 UTC (permalink / raw)
To: unicorn list
Bharanee Rathna <deepfryed@gmail.com> wrote:
> A bit of research suggestsi that rb_thread_wait has
> issues when the select receives ERESTARTNOHAND, any ideas as to why
> this might be happening ?
Not sure, could be a bug in Ruby itself, kernel, or glibc.
I've seen similar reports of this in the past outside of Unicorn but
don't recall ever finding a satisfactory explanation.
> I'm running
>
> $ uname -a
> Linux bbox 2.6.38-02063806-generic #201105121509 SMP Thu May 12
> 15:14:14 UTC 2011 x86_64 GNU/Linux
>
> $ ruby -v
> ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-linux]
Can you try 1.9.2-p180 or Ruby trunk? Or maybe a different version of
glibc, too. Do you have any non-standard kernel patches/scheduler
configs?
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: leading/trailing linear whitespace in headers
2011-05-27 7:32 0% ` Lawrence Pit
@ 2011-05-30 7:02 0% ` Lawrence Pit
0 siblings, 0 replies; 200+ results
From: Lawrence Pit @ 2011-05-30 7:02 UTC (permalink / raw)
To: unicorn list
Cheered too early after all, just got one again:
E, [2011-05-30T16:59:36.005000 #7351] ERROR -- : worker=0 PID:7352
timeout (60.004931s > 60s), killing
E, [2011-05-30T16:59:36.058276 #7351] ERROR -- : reaped
#<Process::Status: pid=7352,signaled(SIGKILL=9)> worker=0
I, [2011-05-30T16:59:36.059122 #7351] INFO -- : worker=0 spawning...
I, [2011-05-30T16:59:36.062990 #8505] INFO -- : worker=0 spawned pid=8505
I, [2011-05-30T16:59:36.063395 #8505] INFO -- : Refreshing Gem list
=> ruby 1.8.7 (i686-darwin10.4.0) [2010-04-19] Ruby Enterprise Edition
worker=0 ready
Cheers,
Lawrence
> Hi Eric,
>
> I thought I'll wait a few days before replying just to make sure:
> believe it or not, since I upgraded 4 days ago to kgio 2.4.1 not once
> did I run into this issue. While before that unicorn would timeout at
> least once every hour, sometimes a dozen times in a row.
>
> I don't run through nginx on my dev machine, just straight into
> unicorn_rails using mostly Chrome 11 and FF 4. I use:
>
> ruby 1.8.7 (2010-04-19 patchlevel 253) [i686-darwin10.4.0], MBARI
> 0x6770, Ruby Enterprise Edition 2010.02
>
>
>
> Cheers,
> Lawrence
>
>> Hi Eric,
>>> Since I upgraded from unicorn 1 to 3, Unicorn will freeze for 60
>>> seconds at random moments, and then restart. Only on my dev machine.
>>> Not in 1 project, but in all my projects that use unicorn. I get no
>>> log output, it just freezes for 60 seconds. Strangely this happens
>>> significantly more often with using Chrome as a client than with
>>> Firefox.
>> Even through nginx? Which Ruby version is it?
>>
>> The bug I'm referring to in this thread is only for /request/ headers,
>> and I don't think any common HTTP clients send trailing whitespace.
>>
>>> So I hope this will fix that, though I have no idea if it's related
>>> in any way. I was thinking it may also have to do with unicorn not
>>> officially supporting Mac OS X.
>> I'm sure you're not the only OS X Unicorn user, perhaps somebody else
>> knows what's going on...
>>
>> If it's kgio-related, but I think Jeremy fixed all the issues under
>> OpenBSD with kgio 2.4.0 and some of that probably helped other
>> *BSD-based systems. I've been meaning to setup a VM on FreeBSD
>> again but haven't had the time.
>>
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: leading/trailing linear whitespace in headers
2011-05-21 5:57 3% ` Eric Wong
@ 2011-05-27 7:32 0% ` Lawrence Pit
2011-05-30 7:02 0% ` Lawrence Pit
0 siblings, 1 reply; 200+ results
From: Lawrence Pit @ 2011-05-27 7:32 UTC (permalink / raw)
To: unicorn list
Hi Eric,
I thought I'll wait a few days before replying just to make sure:
believe it or not, since I upgraded 4 days ago to kgio 2.4.1 not once
did I run into this issue. While before that unicorn would timeout at
least once every hour, sometimes a dozen times in a row.
I don't run through nginx on my dev machine, just straight into
unicorn_rails using mostly Chrome 11 and FF 4. I use:
ruby 1.8.7 (2010-04-19 patchlevel 253) [i686-darwin10.4.0], MBARI
0x6770, Ruby Enterprise Edition 2010.02
Cheers,
Lawrence
> Hi Eric,
>> Since I upgraded from unicorn 1 to 3, Unicorn will freeze for 60
>> seconds at random moments, and then restart. Only on my dev machine.
>> Not in 1 project, but in all my projects that use unicorn. I get no
>> log output, it just freezes for 60 seconds. Strangely this happens
>> significantly more often with using Chrome as a client than with
>> Firefox.
> Even through nginx? Which Ruby version is it?
>
> The bug I'm referring to in this thread is only for /request/ headers,
> and I don't think any common HTTP clients send trailing whitespace.
>
>> So I hope this will fix that, though I have no idea if it's related
>> in any way. I was thinking it may also have to do with unicorn not
>> officially supporting Mac OS X.
> I'm sure you're not the only OS X Unicorn user, perhaps somebody else
> knows what's going on...
>
> If it's kgio-related, but I think Jeremy fixed all the issues under
> OpenBSD with kgio 2.4.0 and some of that probably helped other
> *BSD-based systems. I've been meaning to setup a VM on FreeBSD
> again but haven't had the time.
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* [PATCH] doc: add Links page to help folks find relevant info
@ 2011-05-23 18:37 5% Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2011-05-23 18:37 UTC (permalink / raw)
To: mongrel-unicorn
Older announcements on our mailing list could be harder
to find.
---
I just pushed this out to unicorn.git and
http://unicorn.bogomips.org/Links.html
If there are any other project announcements I missed here, please let
us know, thanks!
.document | 1 +
Links | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 54 insertions(+), 0 deletions(-)
create mode 100644 Links
diff --git a/.document b/.document
index 317e36b..8c7b7cb 100644
--- a/.document
+++ b/.document
@@ -17,3 +17,4 @@ unicorn_1
unicorn_rails_1
ISSUES
Sandbox
+Links
diff --git a/Links b/Links
new file mode 100644
index 0000000..e7f5e60
--- /dev/null
+++ b/Links
@@ -0,0 +1,53 @@
+= Related Projects
+
+If you're interested in \Unicorn, you may be interested in some of the projects
+listed below. If you have any links to add/change/remove, please tell us at
+mailto:mongrel-unicorn@rubyforge.org!
+
+== Disclaimer
+
+The \Unicorn project is not responsible for the content in these links.
+Furthermore, the \Unicorn project has never, does not and will never endorse:
+
+* any for-profit entities or services
+* any non-{Free Software}[http://www.gnu.org/philosophy/free-sw.html]
+
+The existence of these links does not imply endorsement of any entities
+or services behind them.
+
+=== For use with \Unicorn
+
+* {Bluepill}[https://github.com/arya/bluepill] -
+ a simple process monitoring tool written in Ruby
+
+* {golden_brindle}[https://github.com/simonoff/golden_brindle] - tool to
+ manage multiple \Unicorn instances/applications on a single server
+
+* {raindrops}[http://raindrops.bogomips.org/] - real-time stats for
+ preforking Rack servers
+
+=== \Unicorn is written to work with
+
+* {Rack}[http://rack.rubyforge.org/] - a minimal interface between webservers
+ supporting Ruby and Ruby frameworks
+
+* {Ruby}[http://ruby-lang.org/] - the programming language of Rack and \Unicorn
+
+* {nginx}[http://nginx.org/] - the reverse proxy for use with \Unicorn
+
+* {kgio}[http://bogomips.org/kgio/] - the I/O library written for \Unicorn
+
+=== Derivatives
+
+* {Green Unicorn}[http://gunicorn.org/] - a Python version of \Unicorn
+
+* {Rainbows!}[http://rainbows.rubyforge.org/] - \Unicorn for sleepy
+ apps and slow clients.
+
+=== Prior Work
+
+* {Mongrel}[http://mongrel.rubyforge.org/] - the awesome webserver \Unicorn is
+ based on
+
+* {david}[http://bogomips.org/david.git] - a tool to explain why you need
+ nginx in front of \Unicorn
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 5%]
* Re: leading/trailing linear whitespace in headers
@ 2011-05-21 5:57 3% ` Eric Wong
2011-05-27 7:32 0% ` Lawrence Pit
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2011-05-21 5:57 UTC (permalink / raw)
To: unicorn list
Lawrence Pit <lawrence.pit@gmail.com> wrote:
> Hi Eric,
>
> Since I upgraded from unicorn 1 to 3, Unicorn will freeze for 60
> seconds at random moments, and then restart. Only on my dev machine.
> Not in 1 project, but in all my projects that use unicorn. I get no
> log output, it just freezes for 60 seconds. Strangely this happens
> significantly more often with using Chrome as a client than with
> Firefox.
Even through nginx? Which Ruby version is it?
The bug I'm referring to in this thread is only for /request/ headers,
and I don't think any common HTTP clients send trailing whitespace.
> So I hope this will fix that, though I have no idea if it's related
> in any way. I was thinking it may also have to do with unicorn not
> officially supporting Mac OS X.
I'm sure you're not the only OS X Unicorn user, perhaps somebody else
knows what's going on...
If it's kgio-related, but I think Jeremy fixed all the issues under
OpenBSD with kgio 2.4.0 and some of that probably helped other
*BSD-based systems. I've been meaning to setup a VM on FreeBSD
again but haven't had the time.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* [RFC/PATCH] LICENSE: add GPLv3 to license terms
@ 2011-04-28 0:59 7% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2011-04-28 0:59 UTC (permalink / raw)
To: Zed A. Shaw, Evan Weaver; +Cc: mongrel-unicorn
Here's a proposed patch for the exact wording:
diff --git a/LICENSE b/LICENSE
index d48c2d4..386aa40 100644
--- a/LICENSE
+++ b/LICENSE
@@ -1,8 +1,17 @@
Unicorn is copyrighted free software by all contributors, see logs in
-revision control for names and email addresses of all of them. You can
-redistribute it and/or modify it under either the terms of the
-{GPL2}[http://www.gnu.org/licenses/gpl-2.0.txt] (see link:COPYING) or
-the conditions below:
+revision control for names and email addresses of all of them.
+
+You can redistribute it and/or modify it under either the terms of the
+GNU General Public License (GPL) as published by the Free Software
+Foundation (FSF), version {3.0}[http://www.gnu.org/licenses/gpl-3.0.txt]
+or version {2.0}[http://www.gnu.org/licenses/gpl-2.0.txt]
+or the Ruby-specific license terms (see below).
+
+The unicorn project leader (Eric Wong) reserves the right to add future
+versions of the GPL (and no other licenses) as published by the FSF to
+the licensing terms.
+
+=== Ruby-specific terms (if you're not using the GPLv2/GPLv3)
1. You may make and give away verbatim copies of the source form of the
software without restriction, provided that you duplicate all of the
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 7%]
* Re: Unicorn / Daemontools
2011-04-25 18:34 3% ` Eric Wong
@ 2011-04-25 19:03 0% ` Curtis j Schofield
0 siblings, 0 replies; 200+ results
From: Curtis j Schofield @ 2011-04-25 19:03 UTC (permalink / raw)
To: unicorn list
On Mon, Apr 25, 2011 at 11:34 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Curtis j Schofield <curtis.schofield@gmail.com> wrote:
>> I tried to get Daemontools and Unicorn working together a while back -
>> there are issues on USR2 restart because of the pid
>> change - I'm hoping someone in the community will have some
>> understanding of this issue
>
> I have no experience with daemontools directly, but I expect any
> solutions people found to make daemontools work with nginx USR2
> would also work for unicorn since they have the same process/signal
> model.
>
> Maybe a hacky way would be to have daemontools run this wrapper
> script instead of Unicorn:
>
> -------------------------------- 8< -------------------------
> #!/bin/sh
> set -e
>
> # this script is totally untested and written by someone who's never
> # used daemontools
>
> # start Unicorn in the background:
> bundle exec unicorn -D ...
>
> # forward signals received in this wrapper to the Unicorn process:
> for sig in HUP USR1 USR2 QUIT TERM QUIT
> do
> trap 'kill -'$sig' $(cat $UNICORN_PID_FILE)' $sig
> done
>
> # loop forever while Unicorn has its pid file
> # a smarter, Linux-only version of this would use inotify instead
> while test -f $UNICORN_PID_FILE
> do
> sleep 1
> done
>
Eric! This is fascinating!
If i run a wrapper with unicorn as a child process - i can detect the
absence of the wrapper - and
i can detect the absence of the pid file - but i cannot detect a hard
fail in the unicorn process unless i have some kind of pipe
open to the child and register that failure.
Is my understanding correct?
Daemontools is design to take a process that is running in the
foreground and monitor it - keep it alive - the breakdown in unicorn
is when a USR2 arrives at unicorn - and the pid switch occurs - daemon
tools believes it has lost the process.
I see this as a design flaw in all pid based monitoring solutions - in
my experiences.
> --
> Eric Wong
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>
--
make haste slowly \
festina lente \
-
mobile +1_415_632_6001
curtis.schofield@gmail.com
http://robotarmyma.de
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Unicorn / Daemontools
@ 2011-04-25 18:34 3% ` Eric Wong
2011-04-25 19:03 0% ` Curtis j Schofield
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2011-04-25 18:34 UTC (permalink / raw)
To: unicorn list
Curtis j Schofield <curtis.schofield@gmail.com> wrote:
> I tried to get Daemontools and Unicorn working together a while back -
> there are issues on USR2 restart because of the pid
> change - I'm hoping someone in the community will have some
> understanding of this issue
I have no experience with daemontools directly, but I expect any
solutions people found to make daemontools work with nginx USR2
would also work for unicorn since they have the same process/signal
model.
Maybe a hacky way would be to have daemontools run this wrapper
script instead of Unicorn:
-------------------------------- 8< -------------------------
#!/bin/sh
set -e
# this script is totally untested and written by someone who's never
# used daemontools
# start Unicorn in the background:
bundle exec unicorn -D ...
# forward signals received in this wrapper to the Unicorn process:
for sig in HUP USR1 USR2 QUIT TERM QUIT
do
trap 'kill -'$sig' $(cat $UNICORN_PID_FILE)' $sig
done
# loop forever while Unicorn has its pid file
# a smarter, Linux-only version of this would use inotify instead
while test -f $UNICORN_PID_FILE
do
sleep 1
done
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Unicorn error
2011-04-07 21:11 2% Unicorn error Ernesto Rocha
@ 2011-04-07 22:04 0% ` Clifton King
0 siblings, 0 replies; 200+ results
From: Clifton King @ 2011-04-07 22:04 UTC (permalink / raw)
To: unicorn list
Are permissions set correctly in all of your application folders?
/usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/util.rb:19:in `chown': Operation not permitted -
/home/user/project/shared/log/unicorn.stderr.log (Errno::EPERM)
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
Looks to me you may need to do a chown -r app_user /app_directory/
where app_user is the user unicorn is running on. Does unicorn work
with sudo?
On Thu, Apr 7, 2011 at 4:11 PM, Ernesto Rocha <ernestorrocha@gmail.com> wrote:
>
> Hi guys,
>
> These days I'm experimenting a strange behavior from Unicorn. Now the issue is,
> when I try to access a page it's always times out, so, on browser I see:
>
> Nginx - "bad gateway - timed out" page error
>
> When i start unicorn with -d parameter I only see:
>
>
> {:daemonize=>false,
> :app=>
> #<Proc:0x00007feee244d2d8@/usr/local/rvm/gems/ruby-1.8.7-
> p302@project/gems/unicorn-3.5.0/bin/unicorn_rails:135>,
> :unicorn_options=>
> {:config_file=>"/home/user/project/current/config/unicorn.rb",
> :listeners=>[]}}
> Exception `Errno::EEXIST' at /usr/local/rvm/rubies/ruby-1.8.7-
> p302/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/cache
> Exception `Errno::EEXIST' at /usr/local/rvm/rubies/ruby-1.8.7-
> p302/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/pids
> Exception `Errno::EEXIST' at /usr/local/rvm/rubies/ruby-1.8.7-
> p302/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/sessions
> Exception `Errno::EEXIST' at /usr/local/rvm/rubies/ruby-1.8.7-
> p302/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/sockets
>
>
> And at unicorn.stderr.log which is about 2gb now with these lines repeated over
> and over again:
>
> worker=0 spawning...
> worker=1 spawning...
> worker=0 spawned pid=30557
> /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/util.rb:19:in `chown': Operation not permitted -
> /home/user/project/shared/log/unicorn.stderr.log (Errno::EPERM)
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/util.rb:19:in `chown_logs'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/util.rb:18:in `each_object'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/util.rb:18:in `chown_logs'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/worker.rb:31:in `user'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/http_server.rb:561:in `init_worker_process'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/http_server.rb:578:in `worker_loop'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/http_server.rb:495:in `spawn_missing_workers'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/http_server.rb:492:in `fork'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/http_server.rb:492:in `spawn_missing_workers'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/http_server.rb:488:in `each'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/http_server.rb:488:in `spawn_missing_workers'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/http_server.rb:502:in `maintain_worker_count'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/http_server.rb:161:in `start'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn.rb:13:in `run'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/bin/unicorn_rails:208
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/bin/unicorn_rails:19:in
> `load'
> from /usr/local/rvm/gems/ruby-1.8.7-p302@project/bin/unicorn_rails:19
> master process ready
> worker=1 spawned pid=30558
> /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
> 3.5.0/lib/unicorn/util.rb:19:in `chown': Operation not permitted -
> /home/user/project/shared/log/unicorn.stderr.log (Errno::EPERM)
> .... and on....
>
> $ rails -v
> Rails 3.0.6
>
> Using rack (1.2.2)
>
> $unicorn -v
> unicorn v3.5.0
>
> Ubuntu 10.10
>
> $ nginx -v
> nginx version: nginx/0.7.67
>
> I don't know what more information you may need. But, that's it. I don't have
> any idea to fix this. Any thought ?
>
> Thansk,
> Ernesto
>
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Unicorn error
@ 2011-04-07 21:11 2% Ernesto Rocha
2011-04-07 22:04 0% ` Clifton King
0 siblings, 1 reply; 200+ results
From: Ernesto Rocha @ 2011-04-07 21:11 UTC (permalink / raw)
To: mongrel-unicorn
Hi guys,
These days I'm experimenting a strange behavior from Unicorn. Now the issue is,
when I try to access a page it's always times out, so, on browser I see:
Nginx - "bad gateway - timed out" page error
When i start unicorn with -d parameter I only see:
{:daemonize=>false,
:app=>
#<Proc:0x00007feee244d2d8@/usr/local/rvm/gems/ruby-1.8.7-
p302@project/gems/unicorn-3.5.0/bin/unicorn_rails:135>,
:unicorn_options=>
{:config_file=>"/home/user/project/current/config/unicorn.rb",
:listeners=>[]}}
Exception `Errno::EEXIST' at /usr/local/rvm/rubies/ruby-1.8.7-
p302/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/cache
Exception `Errno::EEXIST' at /usr/local/rvm/rubies/ruby-1.8.7-
p302/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/pids
Exception `Errno::EEXIST' at /usr/local/rvm/rubies/ruby-1.8.7-
p302/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/sessions
Exception `Errno::EEXIST' at /usr/local/rvm/rubies/ruby-1.8.7-
p302/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/sockets
And at unicorn.stderr.log which is about 2gb now with these lines repeated over
and over again:
worker=0 spawning...
worker=1 spawning...
worker=0 spawned pid=30557
/usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/util.rb:19:in `chown': Operation not permitted -
/home/user/project/shared/log/unicorn.stderr.log (Errno::EPERM)
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/util.rb:19:in `chown_logs'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/util.rb:18:in `each_object'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/util.rb:18:in `chown_logs'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/worker.rb:31:in `user'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/http_server.rb:561:in `init_worker_process'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/http_server.rb:578:in `worker_loop'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/http_server.rb:495:in `spawn_missing_workers'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/http_server.rb:492:in `fork'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/http_server.rb:492:in `spawn_missing_workers'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/http_server.rb:488:in `each'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/http_server.rb:488:in `spawn_missing_workers'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/http_server.rb:502:in `maintain_worker_count'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/http_server.rb:161:in `start'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn.rb:13:in `run'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/bin/unicorn_rails:208
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/bin/unicorn_rails:19:in
`load'
from /usr/local/rvm/gems/ruby-1.8.7-p302@project/bin/unicorn_rails:19
master process ready
worker=1 spawned pid=30558
/usr/local/rvm/gems/ruby-1.8.7-p302@project/gems/unicorn-
3.5.0/lib/unicorn/util.rb:19:in `chown': Operation not permitted -
/home/user/project/shared/log/unicorn.stderr.log (Errno::EPERM)
.... and on....
$ rails -v
Rails 3.0.6
Using rack (1.2.2)
$unicorn -v
unicorn v3.5.0
Ubuntu 10.10
$ nginx -v
nginx version: nginx/0.7.67
I don't know what more information you may need. But, that's it. I don't have
any idea to fix this. Any thought ?
Thansk,
Ernesto
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: [RFC/PATCH] Bundler/Sandbox documentation updates
2011-03-10 3:30 3% ` Lawrence Pit
@ 2011-03-10 21:29 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2011-03-10 21:29 UTC (permalink / raw)
To: unicorn list
Lawrence Pit <lawrence.pit@gmail.com> wrote:
> Eric Wong <normalperson@yhbt.net> wrote:
>> I've tried this a few times, and everytime I get something like this:
>>> https://gist.github.com/331b0decab62fd58483c
>> Yikes, it looks like the UNICORN_FD env is getting clobbered somehow.
>> Not sure what could be causing that.
>>
>>> If I revert back to setting the GEM_HOME, GEM_PATH and PATH in the
>>> before_exec it works fine.
> > Which Bundler version is this with?
>
> Bundler 1.0.10
Odd, I actually used this in my Rainbows! config file to switch an
Isolate deploy to Bundler (1.0.10) yesterday. Everything for Rainbows!
applies to Unicorn, too).
# switching from Isolate to Bundler:
if ENV["GEM_HOME"] =~ %r{/isolate/}
ENV.delete "GEM_HOME"
ENV.delete "GEM_PATH"
# don't need anything else in $PATH for a web server
ENV["PATH"] = "/home/ew/ruby-1.9.2/bin"
# START_CTX is considered a stable interface in Unicorn
start_ctx = Unicorn::HttpServer::START_CTX
start_ctx[0] = "bundle"
# it's even possible to use USR2 to switch between Unicorn and
# Rainbows! without any downtime :)
start_ctx[:argv] = %w(exec rainbows).concat(start_ctx[:argv])
end
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: [RFC/PATCH] Bundler/Sandbox documentation updates
2011-03-10 0:52 3% ` Eric Wong
@ 2011-03-10 3:30 3% ` Lawrence Pit
2011-03-10 21:29 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Lawrence Pit @ 2011-03-10 3:30 UTC (permalink / raw)
To: unicorn list
> Which Bundler version is this with?
Bundler 1.0.10
Cheers,
Lawrence
> I've tried this a few times, and everytime I get something like this:
>> https://gist.github.com/331b0decab62fd58483c
> Yikes, it looks like the UNICORN_FD env is getting clobbered somehow.
> Not sure what could be causing that.
>
>> If I revert back to setting the GEM_HOME, GEM_PATH and PATH in the
>> before_exec it works fine.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: [RFC/PATCH] Bundler/Sandbox documentation updates
2011-03-09 10:39 0% ` Lawrence Pit
@ 2011-03-10 0:52 3% ` Eric Wong
2011-03-10 3:30 3% ` Lawrence Pit
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2011-03-10 0:52 UTC (permalink / raw)
To: unicorn list
Lawrence Pit <lawrence.pit@gmail.com> wrote:
> Hi Eric,
>
> I tested this out:
Thanks for taking your time to test.
> - in the before_exec and after_fork I log PATH GEM_HOME GEM_PATH
> BUNDLE_GEMFILE for inspection after deployment
>
> - deploy latest release, make sure to shutdown unicorn, then start cleanly
>
> - prune all releases, except the last one
>
> - deploy latest release again (which only sets the BUNDLE_GEMFILE env var)
>
> I've tried this a few times, and everytime I get something like this:
>
> https://gist.github.com/331b0decab62fd58483c
Yikes, it looks like the UNICORN_FD env is getting clobbered somehow.
Not sure what could be causing that.
> If I revert back to setting the GEM_HOME, GEM_PATH and PATH in the
> before_exec it works fine.
Which Bundler version is this with?
> PS. When deploying I use USR2 followed by QUIT
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: [RFC/PATCH] Bundler/Sandbox documentation updates
2011-03-08 4:40 5% [RFC/PATCH] Bundler/Sandbox documentation updates Eric Wong
2011-03-08 14:22 0% ` Justin Giancola
@ 2011-03-09 10:39 0% ` Lawrence Pit
2011-03-10 0:52 3% ` Eric Wong
1 sibling, 1 reply; 200+ results
From: Lawrence Pit @ 2011-03-09 10:39 UTC (permalink / raw)
To: unicorn list
Hi Eric,
I tested this out:
- in the before_exec and after_fork I log PATH GEM_HOME GEM_PATH
BUNDLE_GEMFILE for inspection after deployment
- deploy latest release, make sure to shutdown unicorn, then start cleanly
- prune all releases, except the last one
- deploy latest release again (which only sets the BUNDLE_GEMFILE env var)
I've tried this a few times, and everytime I get something like this:
https://gist.github.com/331b0decab62fd58483c
If I revert back to setting the GEM_HOME, GEM_PATH and PATH in the
before_exec it works fine.
PS. When deploying I use USR2 followed by QUIT
Cheers,
Lawrence
> I started playing around with Bundler 1.0.10 today and noticed it's
> quite different than previous versions (based on my limited experiences)
> and the out-of-the-box experience is pretty good regarding (lack of)
> ENV pollution.
>
> Can any more experienced Bundler (and possibly Capistrano) users
> comment on the below changes and see if they make sense?
>
> Thanks in advance!
>
> diff --git a/Sandbox b/Sandbox
> index d101106..46dfb91 100644
> --- a/Sandbox
> +++ b/Sandbox
> @@ -45,11 +45,20 @@ This is no longer be an issue as of bundler 0.9.17
>
> ref: http://mid.gmane.org/8FC34B23-5994-41CC-B5AF-7198EF06909E@tramchase.com
>
> +=== BUNDLE_GEMFILE for Capistrano users
> +
> +You may need to set or reset the BUNDLE_GEMFILE environment variable in
> +the before_exec hook:
> +
> + before_exec do |server|
> + ENV["BUNDLE_GEMFILE"] = "/path/to/app/current/Gemfile"
> + end
> +
> === Other ENV pollution issues
>
> -You may need to set or reset BUNDLE_GEMFILE, GEM_HOME, GEM_PATH and PATH
> -environment variables in the before_exec hook as illustrated by
> -http://gist.github.com/534668
> +If you're using an older Bundler version (0.9.x), you may need to set or
> +reset GEM_HOME, GEM_PATH and PATH environment variables in the
> +before_exec hook as illustrated by http://gist.github.com/534668
>
> == Isolate
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: [RFC/PATCH] Bundler/Sandbox documentation updates
2011-03-08 4:40 5% [RFC/PATCH] Bundler/Sandbox documentation updates Eric Wong
@ 2011-03-08 14:22 0% ` Justin Giancola
2011-03-09 10:39 0% ` Lawrence Pit
1 sibling, 0 replies; 200+ results
From: Justin Giancola @ 2011-03-08 14:22 UTC (permalink / raw)
To: unicorn list
Setting BUNDLE_GEMFILE in the before_exec hook is the only
Bundler-related Unicorn config I've needed for Bundler >= 1.0.3
For <= 1.0.2 not even this was necessary because the template
executables Bundler generates didn't fully resolve the BUNDLE_GEMFILE
path until 1.0.3
Justin
On Mon, Mar 7, 2011 at 11:40 PM, Eric Wong <normalperson@yhbt.net> wrote:
> I started playing around with Bundler 1.0.10 today and noticed it's
> quite different than previous versions (based on my limited experiences)
> and the out-of-the-box experience is pretty good regarding (lack of)
> ENV pollution.
>
> Can any more experienced Bundler (and possibly Capistrano) users
> comment on the below changes and see if they make sense?
>
> Thanks in advance!
>
> diff --git a/Sandbox b/Sandbox
> index d101106..46dfb91 100644
> --- a/Sandbox
> +++ b/Sandbox
> @@ -45,11 +45,20 @@ This is no longer be an issue as of bundler 0.9.17
>
> ref: http://mid.gmane.org/8FC34B23-5994-41CC-B5AF-7198EF06909E@tramchase.com
>
> +=== BUNDLE_GEMFILE for Capistrano users
> +
> +You may need to set or reset the BUNDLE_GEMFILE environment variable in
> +the before_exec hook:
> +
> + before_exec do |server|
> + ENV["BUNDLE_GEMFILE"] = "/path/to/app/current/Gemfile"
> + end
> +
> === Other ENV pollution issues
>
> -You may need to set or reset BUNDLE_GEMFILE, GEM_HOME, GEM_PATH and PATH
> -environment variables in the before_exec hook as illustrated by
> -http://gist.github.com/534668
> +If you're using an older Bundler version (0.9.x), you may need to set or
> +reset GEM_HOME, GEM_PATH and PATH environment variables in the
> +before_exec hook as illustrated by http://gist.github.com/534668
>
> == Isolate
>
> --
> Eric Wong
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* [RFC/PATCH] Bundler/Sandbox documentation updates
@ 2011-03-08 4:40 5% Eric Wong
2011-03-08 14:22 0% ` Justin Giancola
2011-03-09 10:39 0% ` Lawrence Pit
0 siblings, 2 replies; 200+ results
From: Eric Wong @ 2011-03-08 4:40 UTC (permalink / raw)
To: mongrel-unicorn
I started playing around with Bundler 1.0.10 today and noticed it's
quite different than previous versions (based on my limited experiences)
and the out-of-the-box experience is pretty good regarding (lack of)
ENV pollution.
Can any more experienced Bundler (and possibly Capistrano) users
comment on the below changes and see if they make sense?
Thanks in advance!
diff --git a/Sandbox b/Sandbox
index d101106..46dfb91 100644
--- a/Sandbox
+++ b/Sandbox
@@ -45,11 +45,20 @@ This is no longer be an issue as of bundler 0.9.17
ref: http://mid.gmane.org/8FC34B23-5994-41CC-B5AF-7198EF06909E@tramchase.com
+=== BUNDLE_GEMFILE for Capistrano users
+
+You may need to set or reset the BUNDLE_GEMFILE environment variable in
+the before_exec hook:
+
+ before_exec do |server|
+ ENV["BUNDLE_GEMFILE"] = "/path/to/app/current/Gemfile"
+ end
+
=== Other ENV pollution issues
-You may need to set or reset BUNDLE_GEMFILE, GEM_HOME, GEM_PATH and PATH
-environment variables in the before_exec hook as illustrated by
-http://gist.github.com/534668
+If you're using an older Bundler version (0.9.x), you may need to set or
+reset GEM_HOME, GEM_PATH and PATH environment variables in the
+before_exec hook as illustrated by http://gist.github.com/534668
== Isolate
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 5%]
* Re: rack 1.2 version causing misleading error msg
2010-11-23 23:36 10% rack 1.2 version causing misleading error msg Don Park
@ 2011-02-28 20:51 9% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2011-02-28 20:51 UTC (permalink / raw)
To: unicorn list
Don Park <don.park@gmail.com> wrote:
Received: from rubyforge.org (rubyforge.org [127.0.0.1])
by rubyforge.org (Postfix) with ESMTP id 79A9E1858112;
Mon, 28 Feb 2011 12:12:48 -0500 (EST)
Received: from mail-fx0-f50.google.com (mail-fx0-f50.google.com
[209.85.161.50])
by rubyforge.org (Postfix) with ESMTP id ADC541858112
for <mongrel-unicorn@rubyforge.org>;
Mon, 28 Feb 2011 11:23:10 -0500 (EST)
Received: by fxm18 with SMTP id 18so4518682fxm.23
for <mongrel-unicorn@rubyforge.org>;
Mon, 28 Feb 2011 08:23:09 -0800 (PST)
Received: by 10.223.114.203 with SMTP id f11mr509500faq.20.1298910133851;
Mon, 28 Feb 2011 08:22:13 -0800 (PST)
Received: from [10.0.1.104] (173-8-218-204-Oregon.hfc.comcastbusiness.net
[173.8.218.204])
by mx.google.com with ESMTPS id 21sm1637322fav.41.2011.02.28.08.22.11
(version=SSLv3 cipher=OTHER); Mon, 28 Feb 2011 08:22:12 -0800 (PST)
Date: Tue, 23 Nov 2010 15:36:36 -0800
Btw, something with your local mail queue is off, and it's not
Rubyforge's (nor Google's fault).
> The problem: (note this is the only ruby on the system and rvm/bundler
> is not being used)
>
> $ gem list rails
>
> *** LOCAL GEMS ***
> rails (2.3.10, 2.3.8, 2.3.5)
>
> $ unicorn_rails
> Missing the Rails 2.3.10 gem. Please `gem install -v=2.3.10 rails`,
> update your RAILS_GEM_VERSION setting in config/environment.rb for the
> Rails version you do have installed, or comment out RAILS_GEM_VERSION to
> use the latest version installed.
>
> After much experimentation, the problem is the existence of rack 1.2.1
>
> $ sudo gem uninstall rack
>
> Select gem to uninstall:
> 1. rack-1.1.0
> 2. rack-1.2.1
> 3. All versions
> > 2
>
> donp@donpdonp:~/everyonedelivers$ unicorn_rails
<snip> yup, all is good when only one version of Rack is installed.
This should be fixed in RubyGems 1.6:
http://blog.segment7.net/2011/02/19/rubygems-gem-activation-is-changing
I'm sure the RubyGems testers would appreciate all the testing/feedback
they can get with this since it's been a problem for a while (though
things like bundler/isolate do a great deal to mitigate the issue).
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 9%]
* rack 1.2 version causing misleading error msg
@ 2010-11-23 23:36 10% Don Park
2011-02-28 20:51 9% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Don Park @ 2010-11-23 23:36 UTC (permalink / raw)
To: mongrel-unicorn
The problem: (note this is the only ruby on the system and rvm/bundler
is not being used)
$ gem list rails
*** LOCAL GEMS ***
rails (2.3.10, 2.3.8, 2.3.5)
$ unicorn_rails
I, [2010-11-23T15:03:12.134222 #1297] INFO -- : listening on
addr=0.0.0.0:8080 fd=3
I, [2010-11-23T15:03:12.134499 #1297] INFO -- : worker=0 spawning...
I, [2010-11-23T15:03:12.136120 #1300] INFO -- : worker=0 spawned
pid=1300
I, [2010-11-23T15:03:12.136507 #1300] INFO -- : Refreshing Gem list
I, [2010-11-23T15:03:12.136374 #1297] INFO -- : master process ready
Missing the Rails 2.3.10 gem. Please `gem install -v=2.3.10 rails`,
update your RAILS_GEM_VERSION setting in config/environment.rb for the
Rails version you do have installed, or comment out RAILS_GEM_VERSION to
use the latest version installed.
After much experimentation, the problem is the existence of rack 1.2.1
$ sudo gem uninstall rack
Select gem to uninstall:
1. rack-1.1.0
2. rack-1.2.1
3. All versions
> 2
donp@donpdonp:~/everyonedelivers$ unicorn_rails
I, [2010-11-23T15:26:40.729596 #2202] INFO -- : listening on
addr=0.0.0.0:8080 fd=3
I, [2010-11-23T15:26:40.729869 #2202] INFO -- : worker=0 spawning...
I, [2010-11-23T15:26:40.731081 #2204] INFO -- : worker=0 spawned
pid=2204
I, [2010-11-23T15:26:40.731263 #2204] INFO -- : Refreshing Gem list
I, [2010-11-23T15:26:40.734943 #2202] INFO -- : master process ready
worker=0 ready
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 10%]
* [PATCH] tee_input: remove old *BSD stdio workaround
@ 2011-02-25 17:59 5% Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2011-02-25 17:59 UTC (permalink / raw)
To: mongrel-unicorn
Heads up, I just pushed this out to unicorn.git and it'll be in the
next Unicorn release.
>From cc7e65a1aa1bacc9658a687140011e999be6e3e7 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Fri, 25 Feb 2011 17:54:24 +0000
Subject: [PATCH] tee_input: remove old *BSD stdio workaround
Ruby 1.8.* users should get the latest Ruby 1.8.7 anyways since
they contain critical bugfixes. We don't keep workarounds
forever since the root problem is fixed/worked-around in
upstream and people have had more than a year to upgrade Ruby.
---
KNOWN_ISSUES | 4 ++++
lib/unicorn/tee_input.rb | 1 -
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/KNOWN_ISSUES b/KNOWN_ISSUES
index 259681d..35dc9f3 100644
--- a/KNOWN_ISSUES
+++ b/KNOWN_ISSUES
@@ -8,6 +8,10 @@ acceptable solution. Those issues are documented here.
See http://redmine.ruby-lang.org/issues/show/4338
+* On Ruby 1.8 prior to Ruby 1.8.7-p248, *BSD platforms have a broken
+ stdio that causes failure for file uploads larger than 112K. Upgrade
+ your version of Ruby or continue using Unicorn 1.x/3.4.x.
+
* For notes on sandboxing tools such as Bundler or Isolate,
see the {Sandbox}[link:Sandbox.html] page.
diff --git a/lib/unicorn/tee_input.rb b/lib/unicorn/tee_input.rb
index 6d37f87..637c583 100644
--- a/lib/unicorn/tee_input.rb
+++ b/lib/unicorn/tee_input.rb
@@ -120,7 +120,6 @@ private
def tee(buffer)
if buffer && buffer.size > 0
@tmp.write(buffer)
- @tmp.seek(0, IO::SEEK_END) # workaround FreeBSD/OSX + MRI 1.8.x bug
end
buffer
end
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 5%]
* Re: Forking for background processing with rails/unicorn
2011-02-16 13:06 2% Forking for background processing with rails/unicorn Brian Underwood
@ 2011-02-16 17:41 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2011-02-16 17:41 UTC (permalink / raw)
To: unicorn list
Brian Underwood <bunderwood@rbmtechnologies.com> wrote:
> In the Rails 3 application that I support, we sometimes fork during a
> web request in order to do background processing behind the scenes
> without the user (and the browser connection) to wait for it to
> finish. I realize that a better method would be to have a queue of
> jobs to be processed (I even created a gem called job_boss which works
> well for our case), but it will take us a while to get there, so I'm
> trying to fix this for now.
>
> The problem that I'm finding is that, when I fork, the HTTP connection
> doesn't close. IE doesn't handle this as well and the browser is left
> sitting, waiting for the child process to finish rather than being
> redirected. This functionality worked fine in our application when we
> were using Rails 2.3.5 and Unicorn 1.1.3, but broke when we moved to
> Rails 3 and Unicorn 3.0.0 (we've since moved to Unicorn 3.4.0 and the
> problem remains, I had some hope that Unicorn 3.3.1 might have
> addressed it).
I'm not able to reproduce any difference between 1.x and 3.x in this
regard in forking behavior. I know that the client socket is never
closed on fork by default, so there's probably something else in your
app that changed...
> I've been able to solve this problem temporarily by closing two file
> descriptors manually (#3 and, depending on the version of Rails #6 or
> #7). Obviously this is not ideal. I found the UNICORN_FD environment
> variable when looking through the Unicorn source, but that only seems
> to indicate #3. Where might #6/#7 be coming from?
Whatever is in UNICORN_FD is the listener socket (probably 3), so 6/7 is
probably the client socket, but you should normally close everything in
the forked child for background processing.
The IO.closefrom method in the io-extra[1] gem will get everything
including descriptors opened without a corresponding Ruby object.
If you know everything uses Ruby IO, then walking ObjectSpace works,
too:
# close everything except stdin, stdout and stderr
ObjectSpace.each_object(IO) { |s|
begin
s.close if s.fileno > 2
rescue IOError, Errno::EBADF
# EBADF can come from duplicate IOs due to FD inheritance
end
}
> Is there some way
> that I can determine these without hard-coding the FD #?
lsof or scanning /proc/$$/fd (Linux), but if you have any open socket
connections (memcached/activerecord/net-http-persistent/etc...), you
should close all of those and restart them if necessary in the child.
[1] http://rubyforge.org/projects/shards
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Forking for background processing with rails/unicorn
@ 2011-02-16 13:06 2% Brian Underwood
2011-02-16 17:41 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Brian Underwood @ 2011-02-16 13:06 UTC (permalink / raw)
To: mongrel-unicorn
Hello,
I've been working for a few days on a problem which, after tracking it
down, seems to be related to unicorn. I'm hoping that somebody might
be able to help with information about what's going on.
In the Rails 3 application that I support, we sometimes fork during a
web request in order to do background processing behind the scenes
without the user (and the browser connection) to wait for it to
finish. I realize that a better method would be to have a queue of
jobs to be processed (I even created a gem called job_boss which works
well for our case), but it will take us a while to get there, so I'm
trying to fix this for now.
The problem that I'm finding is that, when I fork, the HTTP connection
doesn't close. IE doesn't handle this as well and the browser is left
sitting, waiting for the child process to finish rather than being
redirected. This functionality worked fine in our application when we
were using Rails 2.3.5 and Unicorn 1.1.3, but broke when we moved to
Rails 3 and Unicorn 3.0.0 (we've since moved to Unicorn 3.4.0 and the
problem remains, I had some hope that Unicorn 3.3.1 might have
addressed it).
I've been able to solve this problem temporarily by closing two file
descriptors manually (#3 and, depending on the version of Rails #6 or
#7). Obviously this is not ideal. I found the UNICORN_FD environment
variable when looking through the Unicorn source, but that only seems
to indicate #3. Where might #6/#7 be coming from? Is there some way
that I can determine these without hard-coding the FD #?
Any help that you can provide would be greatly appreciated,
Brian Underwood
Software Systems Engineer
RBM Technologies, Inc.
215 1st St · Cambridge, MA 02142
call (617) 401-4666
visit www.rbmtechnologies.com
The Power Behind the Planogram™
"This email and any of its attachments may contain proprietary
information, which is privileged, confidential, or subject to
copyrights belonging to RBM Technologies, Inc. This email is intended
solely for the use of the individual or entity to which it is
addressed. If you are not the intended recipient of this email, you
are hereby notified that any dissemination, distribution, copying, or
action taken in relation to the contents of and attachments to this is
strictly prohibited and may be unlawful. If you have received this
email in error, please notify the sender immediately and permanently
delete the original and any copy of this email and any printout. Thank
you."
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: Kernel.srand after_fork
2011-01-28 10:26 3% ` Eric Wong
@ 2011-01-28 10:57 0% ` ghazel
0 siblings, 0 replies; 200+ results
From: ghazel @ 2011-01-28 10:57 UTC (permalink / raw)
To: unicorn list
On Fri, Jan 28, 2011 at 2:26 AM, Eric Wong <normalperson@yhbt.net> wrote:
> ghazel@gmail.com wrote:
>> Hi,
>>
>> We recently noticed random numbers from the Unicorn workers were
>> turning up lots of duplicates across requests. Is it possible that the
>> random seed generated when the ruby interpreter starts is duplicated
>> when the workers are forked, and not re-seeded after fork?
>>
>> If so, should I call Kernel.srand in after_fork, or is this something
>> which should be added to Unicorn?
>
> It looks like a 1.8 bug, which version of Ruby are you running? Ruby
> 1.9.1 actually had a bug where it was reseeded improperly and led to
> segfaults (see KNOWN_ISSUES). 1.9.2 is fine afaik.
REE 1.8.7
So, calling Kernel.srand in after_fork will fix the 1.8 bug and the
1.9.1 bug and work fine on 1.9.2?
-Greg
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Kernel.srand after_fork
@ 2011-01-28 10:26 3% ` Eric Wong
2011-01-28 10:57 0% ` ghazel
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2011-01-28 10:26 UTC (permalink / raw)
To: unicorn list
ghazel@gmail.com wrote:
> Hi,
>
> We recently noticed random numbers from the Unicorn workers were
> turning up lots of duplicates across requests. Is it possible that the
> random seed generated when the ruby interpreter starts is duplicated
> when the workers are forked, and not re-seeded after fork?
>
> If so, should I call Kernel.srand in after_fork, or is this something
> which should be added to Unicorn?
It looks like a 1.8 bug, which version of Ruby are you running? Ruby
1.9.1 actually had a bug where it was reseeded improperly and led to
segfaults (see KNOWN_ISSUES). 1.9.2 is fine afaik.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Unicorn renaming unicorn.pid.oldbin back to unicorn.pid (or, is unicorn afraid to die?)
@ 2011-01-24 19:09 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2011-01-24 19:09 UTC (permalink / raw)
To: unicorn list
Sean Grove <otokorasii@gmail.com> wrote:
> Whenever I send a USR2 signal to unicorn, it correctly renames the pid
> file from unicorn.pid to unicorn.pid.oldbin, and a new instance starts
> launching. However, almost immediately (~2 seconds), it renames it
> back to unicorn.pid. The new instance of unicorn finished launching to
> find that unicorn.pid is already running, and refuses to start up.
>
> I'm not sure if I've misconfigured something, but I'd love to get to
> the bottom of this!
Are you somehow clearing the UNICORN_FD environment variable in your
master process (perhaps when you load your app). Which version of Ruby
are you using? What does your stderr log say?
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Errors in unicorn 2.0.0 and 2.0.1
2010-11-18 9:21 3% Errors in unicorn 2.0.0 and 2.0.1 gut
@ 2010-11-18 9:51 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-11-18 9:51 UTC (permalink / raw)
To: unicorn list; +Cc: gut
gut <gut4rt@gmail.com> wrote:
> I have this error in unicorn.stderr.log:
>
> Unhandled listen loop exception #<Errno::ENOSYS: Function not
> implemented - accept>.
Which OS do you run?
We switched to kgio in Unicorn 2.x.x, so there may be some unresolved
portability issues.
> In version 1.1.3 all ok.
1.1.x will continue to be supported indefinitely, so feel free to
continue using it as we improve portability of 2.x.x.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Errors in unicorn 2.0.0 and 2.0.1
@ 2010-11-18 9:21 3% gut
2010-11-18 9:51 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: gut @ 2010-11-18 9:21 UTC (permalink / raw)
To: mongrel-unicorn
I have this error in unicorn.stderr.log:
Unhandled listen loop exception #<Errno::ENOSYS: Function not
implemented - accept>.
And the crazy size of unicorn.stderr.log.
In version 1.1.3 all ok.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: error when HUP'ing unicorn
@ 2010-11-12 22:56 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-11-12 22:56 UTC (permalink / raw)
To: Grant Heffernan; +Cc: unicorn list
Grant Heffernan <heffergm@me.com> wrote:
> Anyone come across this one before?
>
> Refreshing Gem list
> error reloading config_file=/data/servers/patch-fe-apache/conf/unicorn.rb: TypeError can't convert Hash into Integer /opt/bcs/packages/ruby-gems-1.8/lib/site_ruby/1.8/rubygems/source_index.rb:89:in `read'
Which version of RubyGems are you using? Looking at my RubyGems 1.3.7 install,
I see this:
88 spec_code = if defined? Encoding then
89 File.read file_name, :encoding => 'UTF-8'
90 else
91 File.read file_name
92 end.untaint
I bet you have an "Encoding" constant defined by your application, and
that's tricking RubyGems into thinking you're running Ruby 1.9, which
you're not. You don't get this error the first time you load your code
because it hasn't loaded your Encoding constant, yet, but HUP will cause
RubyGems to refresh its list of gems.
So rename whatever you're calling "Encoding" since it confuses RubyGems
and will break under Ruby 1.9
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: stop/start workers "by need"
@ 2010-10-29 17:40 4% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-10-29 17:40 UTC (permalink / raw)
To: Anton A. Vesnin; +Cc: mongrel-unicorn
"Anton A. Vesnin" <antonvesnin@gmail.com> wrote:
> Hello to everybody.
> I making shared hosting for rails and rack applications. For app. server i
> userd phusion passenger, but after some issues with that, want to migrate to
> unicorn.
>
> Is there any way to make unicorn stop all workers and start them on first
> request? It'll be really great to have this opportunity.
Hi Anton, there's no current way to do this.
Unlike Apache/Passenger, Unicorn should only be tuned for backend
requirements, never to actual connected clients. Unicorn isn't too
different from prefork Apache when serving requests, it's just the
"marketing" for Unicorn focuses _very_ strongly on its limitations :)
On a memory-constrained box, maybe tailing logs or similar and sending
TTIN/TTOU signals to increment/decrement workers as needed can work. A
smarter version of this would even recognize which endpoints are more/less
expensive and tune the workers accordingly.
A dumb version of this would just be a cronjob that
increments/decrements worker depending on the time of day. If you're
running batch processes at off hours, maybe the dumb version is all you
need :)
I'm strongly against having this logic in Unicorn itself since apps
behave wildly differently depending on how they're implemented. And
most deployments I've supported over the years were better off with
fixed/dedicated resources and letting the OS manage things.
> Reply with Cc:, pleace. Thank you.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 4%]
* [ANN] Unicorn 2.0.0, 1.1.5, 1.0.2 released!
@ 2010-10-28 0:19 2% Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-10-28 0:19 UTC (permalink / raw)
To: mongrel-unicorn
tldr:
2.0.0 - cleanups for Rainbows!, but should be ready for general use
barring portability issues
1.1.5 - bug fixes
1.0.2 - bug fixes
Please send any and all feedback to the mailing list. Do not waste
bandwidth with HTML or signature attachments.
email: mongrel-unicorn@rubyforge.org
git: git://git.bogomips.org/unicorn.git
The longer change summaries/release notes:
== unicorn 2.0.0 - mostly internal cleanups
Despite the version number, this release mostly features
internal cleanups for future versions of Rainbows!. User
visible changes include reductions in CPU wakeups on idle sites
using high timeouts.
Barring possible portability issues due to the introduction of
the kgio library, this release should be ready for all to use.
However, 1.1.x (and possibly 1.0.x) will continue to be
maintained. Unicorn 1.1.5 and 1.0.2 have also been released
with bugfixes found during development of 2.0.0.
== unicorn 1.1.5
This maintenance release fixes several long-standing but
recently-noticed bugs. SIGHUP reloading now correctly restores
default values if they're erased or commented-out in the Unicorn
configuration file. Delays/slowdowns in signal handling since
0.990 are fixed, too.
== unicorn 1.0.2
This is the latest maintenance release of the 1.0.x series.
All users are encouraged to upgrade to 1.1.x stable series
and report bugs there.
Shortlog of changes since 1.0.1:
Eric Wong (8):
SIGTTIN works after SIGWINCH
fix delays in signal handling
Rakefile: don't post freshmeat on empty changelogs
Rakefile: capture prerelease tags
configurator: use "__send__" instead of "send"
configurator: reloading with unset values restores default
gemspec: depend on Isolate 3.0.0 for dev
doc: stop using deprecated rdoc CLI options
==
Have fun!
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: 502 bad gateway on nginx with recv() failed
2010-10-22 21:14 3% ` Eric Wong
@ 2010-10-23 4:48 2% ` Naresh V
0 siblings, 0 replies; 200+ results
From: Naresh V @ 2010-10-23 4:48 UTC (permalink / raw)
To: unicorn list
On 23 October 2010 02:44, Eric Wong <normalperson@yhbt.net> wrote:
> Naresh V <nareshov@gmail.com> wrote:
>> Hi,
>>
>> I'm serving the puppetmaster application with its config.ru through
>> unicorn - proxied by nginx.
>> I'm using unix sockets, 4 workers, and 2048 backlog.
>>
>> The clients - after their typical "puppet run" - send back a report to
>> the master in YAML.
>> Some clients whose reports tend to be large (close to 2mb) get a 502
>> bad gateway error and error out.
>>
>> nginx log:
>>
>> 2010/10/22 14:20:27 [error] 19461#0: *17115 recv() failed (104:
>> Connection reset by peer) while reading response header from upstream,
>> client: 1x.yy.zz.x4, server: , request: "PUT /production/report/nagios
>> HTTP/1.1", upstream:
>> "http://unix:/tmp/.sock:/production/report/nagios", host:
>> "puppet:8140"
>
> Hi Naresh, do you see anything in the Unicorn stderr log file?
Hi Eric, I think I caught it:
E, [2010-10-22T23:03:30.207455 #10184] ERROR -- : worker=2 PID:10206
timeout (60.207392s > 60s), killing
I, [2010-10-22T23:03:31.212533 #10184] INFO -- : reaped
#<Process::Status: pid=10206,signaled(SIGKILL=9)> worker=2
I, [2010-10-22T23:03:31.214768 #10490] INFO -- : worker=2 spawned pid=10490
I, [2010-10-22T23:03:31.221748 #10490] INFO -- : worker=2 ready
> Is the 2mb report part of the response or request? Unicorn should
> have no problems accepting large requests (Rainbows! defaults the
> client_max_body_size to 1mb, just like nginx).
It's part of the PUT request, I guess.
> It could be Unicorn's internal (default 60s) timeout kicking
> in because puppet is slowly reading/generating the 2mb body.
I raised the timeout first to 120, then 180 - and I continued to get
the 502 (with the logs as above)
When I raised it upto 240, puppetd complained:
#-(1)> puppetd -t -v --trace
notice: Ignoring --listen on onetime run
info: Caching catalog for nagios
info: Applying configuration version '1287807847'
notice: Finished catalog run in 25.86 seconds
/usr/lib/ruby/1.8/timeout.rb:54:in `rbuf_fill'
/usr/lib/ruby/1.8/timeout.rb:56:in `timeout'
/usr/lib/ruby/1.8/timeout.rb:76:in `timeout'
/usr/lib/ruby/1.8/net/protocol.rb:132:in `rbuf_fill'
/usr/lib/ruby/1.8/net/protocol.rb:116:in `readuntil'
/usr/lib/ruby/1.8/net/protocol.rb:126:in `readline'
/usr/lib/ruby/1.8/net/http.rb:2020:in `read_status_line'
/usr/lib/ruby/1.8/net/http.rb:2009:in `read_new'
/usr/lib/ruby/1.8/net/http.rb:1050:in `request'
/usr/lib/ruby/1.8/net/http.rb:1037:in `request'
/usr/lib/ruby/1.8/net/http.rb:543:in `start'
/usr/lib/ruby/1.8/net/http.rb:1035:in `request'
/usr/lib/ruby/1.8/net/http.rb:857:in `put'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:90:in `save'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:253:in `save'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector.rb:64:in `save'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:178:in `send_report'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:172:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/1.8/sync.rb:229:in `synchronize'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:103:in `with_client'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:114:in `onetime'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:88:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:287:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:393:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:287:in `run'
/usr/sbin/puppetd:4
err: Could not run Puppet configuration client: execution expired
> Also, which version of Unicorn and nginx is this?
unicorn (1.1.4) and nginx-0.8.49-1.el5
>> I was getting the same thing earlier when I had unicorn listening on
>> TCP sockets instead of UNIX sockets. And I had a lot of connections in
>> TIME_WAIT:
>>
>> tcp 0 0 127.0.0.1:8141 127.0.0.1:54507
>> TIME_WAIT -
>> tcp 0 0 127.0.0.1:8141 127.0.0.1:57322
>> TIME_WAIT -
>>
>> Fluctuating all the way from 20 to 800. A quick restart of nginx
>> tended to bring the number down.
>
> Having many TIME_WAIT sockets is normal and expected when you're
> starting/stopping lots of TCP connections. It's nothing to worry about
> unless you get several thousands of requests/second, and then you should
> apply tcp_tw_reuse/tcp_tw_recycle as mentioned in
> http://unicorn.bogomips.org/TUNING.html (or switch to UNIX domain
> sockets and use nginx for keepalive).
>
> --
> Eric Wong
-Naresh V.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: 502 bad gateway on nginx with recv() failed
@ 2010-10-22 21:14 3% ` Eric Wong
2010-10-23 4:48 2% ` Naresh V
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2010-10-22 21:14 UTC (permalink / raw)
To: unicorn list
Naresh V <nareshov@gmail.com> wrote:
> Hi,
>
> I'm serving the puppetmaster application with its config.ru through
> unicorn - proxied by nginx.
> I'm using unix sockets, 4 workers, and 2048 backlog.
>
> The clients - after their typical "puppet run" - send back a report to
> the master in YAML.
> Some clients whose reports tend to be large (close to 2mb) get a 502
> bad gateway error and error out.
>
> nginx log:
>
> 2010/10/22 14:20:27 [error] 19461#0: *17115 recv() failed (104:
> Connection reset by peer) while reading response header from upstream,
> client: 1x.yy.zz.x4, server: , request: "PUT /production/report/nagios
> HTTP/1.1", upstream:
> "http://unix:/tmp/.sock:/production/report/nagios", host:
> "puppet:8140"
Hi Naresh, do you see anything in the Unicorn stderr log file?
Is the 2mb report part of the response or request? Unicorn should
have no problems accepting large requests (Rainbows! defaults the
client_max_body_size to 1mb, just like nginx).
It could be Unicorn's internal (default 60s) timeout kicking
in because puppet is slowly reading/generating the 2mb body.
Also, which version of Unicorn and nginx is this?
> I was getting the same thing earlier when I had unicorn listening on
> TCP sockets instead of UNIX sockets. And I had a lot of connections in
> TIME_WAIT:
>
> tcp 0 0 127.0.0.1:8141 127.0.0.1:54507
> TIME_WAIT -
> tcp 0 0 127.0.0.1:8141 127.0.0.1:57322
> TIME_WAIT -
>
> Fluctuating all the way from 20 to 800. A quick restart of nginx
> tended to bring the number down.
Having many TIME_WAIT sockets is normal and expected when you're
starting/stopping lots of TCP connections. It's nothing to worry about
unless you get several thousands of requests/second, and then you should
apply tcp_tw_reuse/tcp_tw_recycle as mentioned in
http://unicorn.bogomips.org/TUNING.html (or switch to UNIX domain
sockets and use nginx for keepalive).
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: completely stumped by problem encountered replacing running unicorn
2010-10-14 5:50 0% ` Lawrence Pit
@ 2010-10-14 23:01 0% ` Justin Giancola
0 siblings, 0 replies; 200+ results
From: Justin Giancola @ 2010-10-14 23:01 UTC (permalink / raw)
To: unicorn list
Thanks, Lawrence.
ENV pollution was indeed the problem. The aforementioned exception was
being caused by by Bundler 0.7 having set ENV['RUBYOPT'] to
"-r<application root>/gems/environment.rb". After clearing that and
setting my paths properly it worked.
Thank you very much for pointing me in the right direction.
Justin
On Thu, Oct 14, 2010 at 1:50 AM, Lawrence Pit <lawrence.pit@gmail.com> wrote:
> Hi Justin,
>
> See the paragraph "Other ENV pollution issues" at
> http://unicorn.bogomips.org/Sandbox.html
>
>
> Cheers,
> Lawrence
>
>> Hello,
>>
>> First off, many thanks to all those who have contributed to this great
>> project. I have been running Unicorn in production for quite some time
>> now. It hass been very reliable and I have really enjoyed being able
>> to deploy frequently without downtime or even dropped connections.
>>
>> I have used the USR2+QUIT upgrade procedure as described in SIGNALS
>> since I started using Unicorn and it works great. However, while
>> upgrading Bundler on my server the other day, an upgrade failed for
>> the first time. The upgrade failed due to a LoadError --<application
>> root>/gems/environment.rb is no longer used in Bundler 1.0 so it was
>> missing from the new application tree.
>>
>> I am using a Capistrano setup so my app is located at
>> /path/to/app/current where current is a symlink to a timestamped
>> release directory. I am calling #working_directory in my unicorn
>> config to set it to the symlinked current path. I am also calling
>> unicorn via a binstub generated by Bundler located at
>> /path/to/app/current/bin/unicorn.
>>
>> I had expected that reexec would pick up the new unicorn and app code
>> because the path to the unicorn executable script, the path to my app,
>> and config files were all identical to those used in the previous
>> deploy. However, this is not what is happening. Rather, it looks like
>> the previous version of the code is trying to reload iteself in the
>> new app tree where files are missing.
>>
>> I am having a very difficult time understanding exactly what files are
>> being reloaded during the reexec. Even my attempts at troubleshooting
>> where the load error is originating have left me completely baffled.
>> In the old app gems/environment.rb is required in a few places but
>> none of those files seem to be reloaded during the reexec. Further, I
>> cannot get this executable swap to work no matter what I try. I have
>> even tried getting rid of the symlinks entirely and changing the
>> contents of the /path/to/app/current in place during the upgrade.
>>
>> I feel like I may be missing something obvious or else I have
>> completely misunderstood how the reload process works. Any insight as
>> to what I should be doing differently would be greatly appreciated.
>>
>>
>> Justin
>> _______________________________________________
>> Unicorn mailing list - mongrel-unicorn@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
>> Do not quote signatures (like this one) or top post when replying
>>
>
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: completely stumped by problem encountered replacing running unicorn
2010-10-14 4:58 2% completely stumped by problem encountered replacing running unicorn Justin Giancola
@ 2010-10-14 5:50 0% ` Lawrence Pit
2010-10-14 23:01 0% ` Justin Giancola
0 siblings, 1 reply; 200+ results
From: Lawrence Pit @ 2010-10-14 5:50 UTC (permalink / raw)
To: unicorn list
Hi Justin,
See the paragraph "Other ENV pollution issues" at
http://unicorn.bogomips.org/Sandbox.html
Cheers,
Lawrence
> Hello,
>
> First off, many thanks to all those who have contributed to this great
> project. I have been running Unicorn in production for quite some time
> now. It hass been very reliable and I have really enjoyed being able
> to deploy frequently without downtime or even dropped connections.
>
> I have used the USR2+QUIT upgrade procedure as described in SIGNALS
> since I started using Unicorn and it works great. However, while
> upgrading Bundler on my server the other day, an upgrade failed for
> the first time. The upgrade failed due to a LoadError --<application
> root>/gems/environment.rb is no longer used in Bundler 1.0 so it was
> missing from the new application tree.
>
> I am using a Capistrano setup so my app is located at
> /path/to/app/current where current is a symlink to a timestamped
> release directory. I am calling #working_directory in my unicorn
> config to set it to the symlinked current path. I am also calling
> unicorn via a binstub generated by Bundler located at
> /path/to/app/current/bin/unicorn.
>
> I had expected that reexec would pick up the new unicorn and app code
> because the path to the unicorn executable script, the path to my app,
> and config files were all identical to those used in the previous
> deploy. However, this is not what is happening. Rather, it looks like
> the previous version of the code is trying to reload iteself in the
> new app tree where files are missing.
>
> I am having a very difficult time understanding exactly what files are
> being reloaded during the reexec. Even my attempts at troubleshooting
> where the load error is originating have left me completely baffled.
> In the old app gems/environment.rb is required in a few places but
> none of those files seem to be reloaded during the reexec. Further, I
> cannot get this executable swap to work no matter what I try. I have
> even tried getting rid of the symlinks entirely and changing the
> contents of the /path/to/app/current in place during the upgrade.
>
> I feel like I may be missing something obvious or else I have
> completely misunderstood how the reload process works. Any insight as
> to what I should be doing differently would be greatly appreciated.
>
>
> Justin
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* completely stumped by problem encountered replacing running unicorn
@ 2010-10-14 4:58 2% Justin Giancola
2010-10-14 5:50 0% ` Lawrence Pit
0 siblings, 1 reply; 200+ results
From: Justin Giancola @ 2010-10-14 4:58 UTC (permalink / raw)
To: mongrel-unicorn
Hello,
First off, many thanks to all those who have contributed to this great
project. I have been running Unicorn in production for quite some time
now. It hass been very reliable and I have really enjoyed being able
to deploy frequently without downtime or even dropped connections.
I have used the USR2+QUIT upgrade procedure as described in SIGNALS
since I started using Unicorn and it works great. However, while
upgrading Bundler on my server the other day, an upgrade failed for
the first time. The upgrade failed due to a LoadError -- <application
root>/gems/environment.rb is no longer used in Bundler 1.0 so it was
missing from the new application tree.
I am using a Capistrano setup so my app is located at
/path/to/app/current where current is a symlink to a timestamped
release directory. I am calling #working_directory in my unicorn
config to set it to the symlinked current path. I am also calling
unicorn via a binstub generated by Bundler located at
/path/to/app/current/bin/unicorn.
I had expected that reexec would pick up the new unicorn and app code
because the path to the unicorn executable script, the path to my app,
and config files were all identical to those used in the previous
deploy. However, this is not what is happening. Rather, it looks like
the previous version of the code is trying to reload iteself in the
new app tree where files are missing.
I am having a very difficult time understanding exactly what files are
being reloaded during the reexec. Even my attempts at troubleshooting
where the load error is originating have left me completely baffled.
In the old app gems/environment.rb is required in a few places but
none of those files seem to be reloaded during the reexec. Further, I
cannot get this executable swap to work no matter what I try. I have
even tried getting rid of the symlinks entirely and changing the
contents of the /path/to/app/current in place during the upgrade.
I feel like I may be missing something obvious or else I have
completely misunderstood how the reload process works. Any insight as
to what I should be doing differently would be greatly appreciated.
Justin
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: unicorn_rails and rails 2.3.8
2010-09-07 19:29 3% unicorn_rails and rails 2.3.8 Matt Smith
@ 2010-09-11 15:42 3% ` Edho P Arief
0 siblings, 0 replies; 200+ results
From: Edho P Arief @ 2010-09-11 15:42 UTC (permalink / raw)
To: unicorn list
On Wed, Sep 8, 2010 at 2:29 AM, Matt Smith <matts@morgansound.com> wrote:
> First off, I love unicorn. Thanks to all who have worked on it.
>
> For the first time, I am trying to run a rails 2.3 app with unicorn. I don't understand what is not set correctly. I have rails 2.3.8 and dependencies installed. I am sure it is something simple.... See output below.
>
> rack (1.2.1, 1.1.0)
You probably want to install rack 1.0.1 and then create a copy of
unicorn_rails startup script and modify it to force load rack of that
version.
--
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* unicorn_rails and rails 2.3.8
@ 2010-09-07 19:29 3% Matt Smith
2010-09-11 15:42 3% ` Edho P Arief
0 siblings, 1 reply; 200+ results
From: Matt Smith @ 2010-09-07 19:29 UTC (permalink / raw)
To: mongrel-unicorn
First off, I love unicorn. Thanks to all who have worked on it.
For the first time, I am trying to run a rails 2.3 app with unicorn. I don't understand what is not set correctly. I have rails 2.3.8 and dependencies installed. I am sure it is something simple.... See output below.
Much thanks!
Matt
config/environment.rb
...
RAILS_GEM_VERSION = '2.3.8' unless defined? RAILS_GEM_VERSION
...
ruby-1.9.2-p0 repositories/rails_apps/fat_free_crm[master]% unicorn_rails
I, [2010-09-07T12:20:54.342354 #9085] INFO -- : reaped #<Process::Status: pid 9087 exit 1> worker=0
I, [2010-09-07T12:20:54.343368 #9085] INFO -- : worker=0 spawning...
I, [2010-09-07T12:20:54.348304 #9088] INFO -- : worker=0 spawned pid=9088
I, [2010-09-07T12:20:54.349106 #9088] INFO -- : Refreshing Gem list
Missing the Rails 2.3.8 gem. Please `gem install -v=2.3.8 rails`, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or comment out RAILS_GEM_VERSION to use the latest version installed.
^CI, [2010-09-07T12:20:56.514921 #9085] INFO -- : reaped #<Process::Status: pid 9088 exit 1> worker=0
I, [2010-09-07T12:20:56.515901 #9085] INFO -- : master complete
ruby-1.9.2-p0 repositories/rails_apps/fat_free_crm[master]% gem list
*** LOCAL GEMS ***
abstract (1.0.0)
actionmailer (3.0.0, 3.0.0.rc, 2.3.8)
actionpack (3.0.0, 3.0.0.rc, 2.3.8)
activemodel (3.0.0, 3.0.0.rc)
activerecord (3.0.0, 3.0.0.rc, 2.3.8)
activeresource (3.0.0, 3.0.0.rc, 2.3.8)
activesupport (3.0.0, 3.0.0.rc, 2.3.8)
arel (1.0.1, 0.4.0)
builder (2.1.2)
bundler (1.0.0.rc.5)
capistrano (2.5.19)
cucumber (0.8.5)
cucumber-rails (0.3.2)
diff-lcs (1.1.2)
erubis (2.6.6)
gherkin (2.1.5)
god (0.11.0)
highline (1.6.1)
hoe (2.6.2)
i18n (0.4.1)
json_pure (1.4.6)
mail (2.2.5)
mime-types (1.16)
mysql (2.8.1)
mysql2 (0.2.3)
net-scp (1.0.3)
net-sftp (2.0.5)
net-ssh (2.0.23)
net-ssh-gateway (1.0.1)
nokogiri (1.4.3.1)
paperclip (2.3.3)
polyglot (0.3.1)
rack (1.2.1, 1.1.0)
rack-mount (0.6.13, 0.6.12, 0.6.11)
rack-test (0.5.4)
rails (3.0.0, 3.0.0.rc, 2.3.8)
railties (3.0.0, 3.0.0.rc)
rake (0.8.7)
rdoc (2.5.11)
rspec (2.0.0.beta.20)
rspec-core (2.0.0.beta.20)
rspec-expectations (2.0.0.beta.20)
rspec-mocks (2.0.0.beta.20)
rspec-rails (2.0.0.beta.20)
rubyforge (2.0.4)
sqlite3-ruby (1.3.1)
term-ansicolor (1.0.5)
test-unit (1.2.3)
thor (0.14.0)
treetop (1.4.8)
trollop (1.16.2)
tzinfo (0.3.23)
unicorn (1.1.3, 1.1.2)
webrat (0.7.2.beta.1)
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Unicorn fails to restart gracefully on capistrano deploy
@ 2010-09-09 23:28 5% Eirik Dentz Sinclair
0 siblings, 0 replies; 200+ results
From: Eirik Dentz Sinclair @ 2010-09-09 23:28 UTC (permalink / raw)
To: mongrel-unicorn; +Cc: tech
First off thanks very much for all the hard work on unicorn. Alas, we've encountered an issue where unicorn fails to spawn new workers that have loaded the incoming revision on a capistrano deploy. I'm not entirely sure the issue is due to unicorn as it appears that bundler was responsible for a similar issue in the past: http://github.com/carlhuda/bundler/issues/issue/259/#comment_180830
But presumably bundler has corrected that issue and any help in sorting out the issue would be greatly appreciated.
We are following EngineYard's instructions for loading unicorn via bundle exec: http://docs.engineyard.com/appcloud/howtos/cutomization/customize-unicorn
So far we've tried deploying with the unicorn config set to both "preload_app true" and "preload_app false".
(unicorn.rb being used: https://gist.github.com/9a208e3d1d1e44161018)
When "preload_app true" is used the "uninitialized constant Prefix::OurCustomApi (NameError)" log entry/stacktrace appears once. And the workers never load the incoming code. So while the incoming code is in place and the symlinks are all updated we're still running the previous revision until a unicorn stop/start or reload is sent.
When "preload_app false" is used the "uninitialized constant Prefix::OurCustomApi (NameError)" log entry/stacktrace is written to the unicorn.stderr.log continuously as it keeps trying to respawn workers in a loop. This goes on until a unicorn stop command is sent. Then a unicorn start can be used to load the incoming revision successfully.
The common deployment stack and versions follow:
Capistrano 2.5.19
Bundler 1.0.0rc6
Rails 2.3.8
Unicorn 1.0.1 (tested under unicorn 1.1.3 with same results)
The deployments differ as follows:
The deployed versioned directory is 20100830230613
The incoming versioned directory is 20100902192111
Code in version 20100830230613 uses our_custom_api.gem version 1.0 via the Gemfile
Code in version 20100830230613 uses the constant OurCustomApi in config/initializers/our_custom_api.rb
Code in version 20100902192111 uses prefix_our_custom_api.gem version 2.0 via the Gemfile
Code in version 20100902192111 uses the constant Prefix::OurCustomApi in config/initializers/our_custom_api.rb
The relevant relevant unicorn.stderr.log can be found below and appear to show some sort of issue where both versioned directories are being loaded into the same process?
Unicorn 1.0.1:
https://gist.github.com/ddc852b23617fc8584e0
Unicorn 1.1.3:
https://gist.github.com/6314ea0e14ff78b4e8dc
Thanks in advance,
Eirik Dentz Sinclair
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 5%]
* Re: Unicorn and home_run
2010-08-25 14:46 3% ` Jeremy Evans
@ 2010-08-26 4:33 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-08-26 4:33 UTC (permalink / raw)
To: unicorn list
Jeremy Evans <jeremyevans0@gmail.com> wrote:
> On Wed, Aug 25, 2010 at 12:50 AM, Eric Wong <normalperson@yhbt.net> wrote:
> > Yeah, I figured using the "home_run" wrapper would be less than
> > ideal since it would get lost during exec upgrades and newer
> > versions of home_run wouldn't get picked up the same way it'd get
> > picked up in a system install.
>
> The home_run wrapper works by modifying the environment (RUBYLIB and
> RUBYOPT). Does the environment get reset during exec upgrades?
The environment is untouched by default. I meant Unicorn can only see
$0 as 'unicorn' or 'unicorn_rails', and never 'home_run', so the
version changes can't be picked up.
> You are correct that newer versions would not get picked up, as it's
> going to hard code a specific gem version.
> > Thanks. I'd be eager to hear how it works out since this could be a
> > popular library very soon :) Is there a home_run mailing list I could
> > follow?
>
> I haven't set up a mailing list for it (you are the first person to
> ask about one), but I've been hanging out by myself in #home_run on
> freenode (IRC).
Ah, I've mostly given up on IRC since I get distracted easily or
everybody pops in at different times and lack of threading makes it hard
to follow. I much prefer the asynchronous nature of email along with
its ease of archival, search, and patch exchange. For intense
emergencies where money is lost for every second something is awry, yes,
IRC is great, but I do Free Software development at a much more relaxed
pace :)
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Unicorn and home_run
@ 2010-08-25 14:46 3% ` Jeremy Evans
2010-08-26 4:33 3% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Jeremy Evans @ 2010-08-25 14:46 UTC (permalink / raw)
To: unicorn list
On Wed, Aug 25, 2010 at 12:50 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Jeremy Evans <jeremyevans0@gmail.com> wrote:
>> > Are you starting it with "home_run unicorn_rails" or did you install
>> > it system-wide?
>>
>> Clifton told me that was working for him. One of the reasons it may
>> work where the other way didn't is that in addition to setting up the
>> load path, it also requires the library up front.
>
> Yeah, I figured using the "home_run" wrapper would be less than
> ideal since it would get lost during exec upgrades and newer
> versions of home_run wouldn't get picked up the same way it'd get
> picked up in a system install.
The home_run wrapper works by modifying the environment (RUBYLIB and
RUBYOPT). Does the environment get reset during exec upgrades?
You are correct that newer versions would not get picked up, as it's
going to hard code a specific gem version.
>> I think this problem is solved in the master branch.
>
> Thanks. I'd be eager to hear how it works out since this could be a
> popular library very soon :) Is there a home_run mailing list I could
> follow?
I haven't set up a mailing list for it (you are the first person to
ask about one), but I've been hanging out by myself in #home_run on
freenode (IRC).
Jeremy
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: javascript disappears
2010-08-18 2:23 3% ` Jimmy Soho
@ 2010-08-18 2:45 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-08-18 2:45 UTC (permalink / raw)
To: unicorn list
Jimmy Soho <jimmy.soho@gmail.com> wrote:
> > Hi Jimmy, Are you deploying with Capistrano and you originally started
> > Unicorn in a working_directory that no longer exists on the filesystem?
> >
> > Under Linux, you can check the working directory of any process
> > with `ls -l /proc/$PID/cwd`
>
> Ah! Yes. I use Capistrano, and it pruned releases. But definitely
> /after/ a new version was deployed.
>
> What I don't understand then though is that I have this in my unicorn
> config file:
>
> working_directory "/srv/app1/current"
>
> How could the new master / workers still be pointing to the old
> directory? Isn't what this working_directory directive is for?
In your Capistrano deploy tasks, do you create/update the current
symlink before you send USR2? You should have the symlink updated
before sending USR2..
Other folks here may have more experience with Capistrano+Unicorn,
maybe they have portable recipes they can share.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: javascript disappears
@ 2010-08-18 2:23 3% ` Jimmy Soho
2010-08-18 2:45 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Jimmy Soho @ 2010-08-18 2:23 UTC (permalink / raw)
To: unicorn list
> Hi Jimmy, Are you deploying with Capistrano and you originally started
> Unicorn in a working_directory that no longer exists on the filesystem?
>
> Under Linux, you can check the working directory of any process
> with `ls -l /proc/$PID/cwd`
Ah! Yes. I use Capistrano, and it pruned releases. But definitely
/after/ a new version was deployed.
What I don't understand then though is that I have this in my unicorn
config file:
working_directory "/srv/app1/current"
How could the new master / workers still be pointing to the old
directory? Isn't what this working_directory directive is for?
Jimmy
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: running unicorn under rvm
2010-08-17 22:37 3% ` Joseph McDonald
@ 2010-08-18 1:08 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-08-18 1:08 UTC (permalink / raw)
To: Joseph McDonald; +Cc: unicorn list
Joseph McDonald <superjoe@gmail.com> wrote:
> I'm sure I'm running the right version of unicorn.
> what's weird is if I remove the reference to TOPLEVEL_BINDING, it works, i.e.:
>
> host, port, set_listener, options, daemonize =
> eval("[ host, port, set_listener, options, daemonize ]")
>
> works, it gets the right port from the config.ru file.
Hm... I'm stumped. However, you're really encouraging me to pause other
projects, work on 2.0 and release it this week/weekend :) I suppose
some of the crazier 2.0 stuff I proposed can wait until 3.x.
> my config.ru file looks like"
> #\ -w -p 4452
> require './mystuff'
> run Sinatra::Application
>
> another strange thing: I need to add the "./" in front of mystuff,
> but when i'm not using rvm (rvm use system), I don't need to do that.
Odd... needing the './' feels like it's using Ruby 1.9.2 or later...
Can you print out RUBY_VERSION in there to be certain?
I just tried rvm for the first time with a fresh user/home directory on my
system and everything works as expected with 1.8.7 (it just picked p302, not
p299, but that shouldn't make a difference...).
> I'm curious if anyone else is using unicorn with rvm and not having
> this problem. I'm guessing it's something weird with my system, but
> not sure.
If you have root on your machine, just try creating a new user and start
with a blank $HOME. I often do that to narrow things down when
debugging/testing code and don't feel like going all the way with chroot
or VM.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: running unicorn under rvm
@ 2010-08-17 22:37 3% ` Joseph McDonald
2010-08-18 1:08 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Joseph McDonald @ 2010-08-17 22:37 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
Thanks Eric, see below:
On Mon, Aug 16, 2010 at 8:52 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Joseph McDonald <superjoe@gmail.com> wrote:
>> unicorn 1.1.2 runs fine under my system ruby, but when trying to run
>> it using rvm, I get:
>>
>>
>> % rvm use 1.8.7
>> info: Using ruby 1.8.7 p299
>>
>> % unicorn
>> /home/joe/.rvm/gems/ruby-1.8.7-p299/gems/unicorn-1.1.2/lib/unicorn/configurator.rb:494:in
>> `eval': undefined local variable or method `host' for main:Object
>> (NameError)
>
> Hi Joseph,
>
> Is there any chance you have an older "unicorn" executable script
> somewhere that gets exposed rvm switches the environment on you? That's
> the only thing I can think of right now.
I'm sure I'm running the right version of unicorn.
what's weird is if I remove the reference to TOPLEVEL_BINDING, it works, i.e.:
host, port, set_listener, options, daemonize =
eval("[ host, port, set_listener, options, daemonize ]")
works, it gets the right port from the config.ru file.
my config.ru file looks like"
#\ -w -p 4452
require './mystuff'
run Sinatra::Application
another strange thing: I need to add the "./" in front of mystuff,
but when i'm not using rvm (rvm use system), I don't need to do that.
I'm curious if anyone else is using unicorn with rvm and not having
this problem. I'm guessing it's something weird with my system, but
not sure.
thanks,
-joe
>
>> line 494 looks like:
>>
>> # XXX ugly as hell, WILL FIX in 2.x (along with Rainbows!/Zbatery)
>
> Yes, I still need to work on 2.x and clean up a lot of the
> ugly internal API bits :)
>
>
> --
> Eric Wong
>
> P.S.: At least nowadays I'm (finally) getting some experience
> developing/supporting applications using Unicorn and Rainbows! (or
> Zbatery). Things like e4d0b226391948ef433f1d0135814315e4c48535 in
> unicorn.git are a direct result of that.
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Problem with x-www-form-urlencoded
2010-07-16 7:54 0% ` Eric Wong
@ 2010-07-16 13:17 0% ` Richard Penwell
0 siblings, 0 replies; 200+ results
From: Richard Penwell @ 2010-07-16 13:17 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
I have used request.body.read as it's only a HTTP form post from an external provider of a fixed size.
Thank you so much, I suppose I figured it out when I noticed that most of those quotes were escaped...
R
On Jul 16, 2010, at 3:54 AM, Eric Wong wrote:
> Richard Penwell <almightylinuxgod@me.com> wrote:
>> On Jul 15, 2010, at 6:40 PM, Eric Wong <normalperson@yhbt.net> wrote:
>>> Richard Penwell <almightylinuxgod@me.com> wrote:
>>>> So I discovered this was a problem whereby request.body.to_s behaves
>>>> differently. I wonder if TeeStream should define to_s as an alias for
>>>> read?
>>>
>>> to_s isn't defined by any version of the Rack spec.
>>>
>>> It's horrible practice to use it, too, since it could be a big upload
>>> that uses all your memory.
>>>
>>> What are you using that does request.body.to_s? Can you change it?
>>>
>> We have an application that forwards requests to staging, dev or
>> production. So it takes the body of the request and forwards it
>> along...
>
> (top-posting corrected)
>
> I would always make it use a read/write loop with some fixed chunk size.
>
> If you don't care about memory usage or if you have nginx properly
> configured to reject large requests (the default of 1M is actually quite
> reasonable), then use "request.body.read" instead since that's the
> supported way to use all Rack apps/middlewares. You can try your apps
> with Rack::Lint middleware loaded during development/testing to catch
> these things.
>
> --
> Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Problem with x-www-form-urlencoded
2010-07-15 23:49 0% ` Richard Penwell
@ 2010-07-16 7:54 0% ` Eric Wong
2010-07-16 13:17 0% ` Richard Penwell
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2010-07-16 7:54 UTC (permalink / raw)
To: Richard Penwell; +Cc: unicorn list
Richard Penwell <almightylinuxgod@me.com> wrote:
> On Jul 15, 2010, at 6:40 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > Richard Penwell <almightylinuxgod@me.com> wrote:
> >> So I discovered this was a problem whereby request.body.to_s behaves
> >> differently. I wonder if TeeStream should define to_s as an alias for
> >> read?
> >
> > to_s isn't defined by any version of the Rack spec.
> >
> > It's horrible practice to use it, too, since it could be a big upload
> > that uses all your memory.
> >
> > What are you using that does request.body.to_s? Can you change it?
> >
> We have an application that forwards requests to staging, dev or
> production. So it takes the body of the request and forwards it
> along...
(top-posting corrected)
I would always make it use a read/write loop with some fixed chunk size.
If you don't care about memory usage or if you have nginx properly
configured to reject large requests (the default of 1M is actually quite
reasonable), then use "request.body.read" instead since that's the
supported way to use all Rack apps/middlewares. You can try your apps
with Rack::Lint middleware loaded during development/testing to catch
these things.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks
@ 2010-07-16 0:47 4% ` Lawrence Pit
0 siblings, 0 replies; 200+ results
From: Lawrence Pit @ 2010-07-16 0:47 UTC (permalink / raw)
To: unicorn list
>> It appears unicorn rolls back by itself when it can't start the new master. Nice!
>>
>> Jamie also mentions to use the shared vendor/bundler_gems path. Though I do use that in all my projects I'm not so sure it's wise to do when you can't afford any downtime. I'll have to wait for unicorn v1.1.3 before I can test whether rolling back will indeed continue with unicorn v1.1.2 instead of v1.1.3 ;o
>>
>
> Hi Lawrence, why does the shared vendor/bundler_gems cause you downtime? From not re-bundling during rollback?
>
> FWIW I made that recommendation because I ran into issues with unicorns not restarting correctly after running `cap deploy:cleanup`, since the `bundle exec` launches a binary with a path like /app/releases/201007125236/bin/unicorn, which goes missing after N deploys. I haven't tested if this applies to more recent versions
>
> Shared bundles are also significantly faster -- `bundle check || bundle install` is ~1s for me vs. several minutes to totally rebundle
>
Hi Jamie, I see what you mean. I haven't tested this yet, so I don't
know for sure if it could cause downtime. I also always use bundle check
|| bundle install to get that time benefit.
My worry was indeed that it might pick a newer unicorn to restart
workers for the old master. I guess that can/should be prevented by
having an on_rollback in my capistrano bundler task.
What is the exact command you use to start unicorn?
What I see is this, I start with:
$ su -l deployer -c "cd /app/current ; bundle exec unicorn_rails -D -c
/app/current/config/unicorn.rb"
My after_fork and before_exec methods output the ENV vars to the unicorn
log. I see for example:
AFTER_FORK: VERSION 1
PATH=/app/releases/20100714054705/vendor/bundler_gems/bin:....
GEM_HOME=/app/releases/20100714054705/vendor/bundler_gems
GEM_PATH=/app/releases/20100714054705/vendor/bundler_gems:/app/releases/20100714054705/vendor/bundler_gems/bundler/gems
BUNDLE_GEMFILE=/app/releases/20100714054705/Gemfile
Note that /app/releases/20100714054705/vendor/bundler_gems is a symlink
to /app/releases/shared/vendor/bundler_gems
When I deploy a new version, symlink /app/current to the new release
directory, and send USR2 :
executing
["/app/releases/20100714054705/vendor/bundler_gems/bin/unicorn_rails",
"-D", "-E", "staging", "-c", "/app/current/config/unicorn.rb"] (in
/app/releases/20100714055624)
BEFORE_EXEC: VERSION 1
PATH=/app/releases/20100714054705/vendor/bundler_gems/bin:....
GEM_HOME=/app/releases/20100714054705/vendor/bundler_gems
GEM_PATH=/app/releases/20100714054705/vendor/bundler_gems:/app/releases/20100714054705/vendor/bundler_gems/bundler/gems
BUNDLE_GEMFILE=/app/releases/20100714054705/Gemfile
I, [2010-07-15T23:31:47.765995 #23084] INFO -- : inherited
addr=/tmp/.unicorn_sock fd=3
I, [2010-07-15T23:31:47.766646 #23084] INFO -- : Refreshing Gem list
/app/releases/20100714055624/.bundle/environment.rb:175: warning:
already initialized constant ENV_LOADED
/app/releases/20100714055624/.bundle/environment.rb:176: warning:
already initialized constant LOCKED_BY
/app/releases/20100714055624/.bundle/environment.rb:177: warning:
already initialized constant FINGERPRINT
/app/releases/20100714055624/.bundle/environment.rb:178: warning:
already initialized constant HOME
/app/releases/20100714055624/.bundle/environment.rb:179: warning:
already initialized constant AUTOREQUIRES
/app/releases/20100714055624/.bundle/environment.rb:181: warning:
already initialized constant SPECS
AFTER_FORK: VERSION 2
PATH=/app/releases/20100714054705/vendor/bundler_gems/bin:....
GEM_HOME=/app/releases/20100714055624/vendor/bundler_gems
GEM_PATH=/app/releases/20100714055624/vendor/bundler_gems:/app/releases/20100714055624/vendor/bundler_gems/bundler/gems
BUNDLE_GEMFILE=/app/releases/20100714054705/Gemfile
What you see here is that the new worker does have correct GEM_HOME and
GEM_PATH values, but the PATH and BUNDLE_GEMFILE values are pointing to
the old dir.
Are those bundler warnings something to worry about?
The BUNDLE_GEMFILE value is worrying I think. I haven't tested this, but
I'm pretty sure when Bundler.setup is called within your app it will
actually setup using the old Gemfile then. So that would mean you need
to reset it somehow? I don't see how at the moment... should unicorn
provide a method similar to +working_directory+ to help ensure the
application always uses the "current" Gemfile (eg
"/app/current/Gemfile") ? Sound kind of strange unicorn should provide
such a method, is there another way?
What about that PATH value? What happens if 10 deployments later the
dir /app/releases/20100714054705 is pruned? I tried. After removing that
dir I could still send a HUP, but when I send a USR2 I get this:
/app/releases/20100714054705/vendor/bundler_gems/gems/unicorn-1.1.2/lib/unicorn.rb:573:in
`exec': No such file or directory -
app/releases/20100714054705/vendor/bundler_gems/bin/unicorn_rails
(Errno::ENOENT)
from
/app/releases/20100714054705/vendor/bundler_gems/gems/unicorn-1.1.2/lib/unicorn.rb:573:in
`reexec'
> since the `bundle exec` launches a binary with a path like
/app/releases/201007125236/bin/unicorn,
> which goes missing after N deploys
That's what I'm seeing. How did using shared vendor/bundler_gems help
you? Because I'm starting with bundle exec using shared
vendor/bundler_gems as well.
Cheers,
Lawrence
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 4%]
* Re: Problem with x-www-form-urlencoded
2010-07-15 22:40 3% ` Eric Wong
@ 2010-07-15 23:49 0% ` Richard Penwell
2010-07-16 7:54 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Richard Penwell @ 2010-07-15 23:49 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
We have an application that forwards requests to staging, dev or production. So it takes the body of the request and forwards it along...
Sent from my iPhone
On Jul 15, 2010, at 6:40 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Richard Penwell <almightylinuxgod@me.com> wrote:
>> So I discovered this was a problem whereby request.body.to_s behaves
>> differently. I wonder if TeeStream should define to_s as an alias for
>> read?
>
> to_s isn't defined by any version of the Rack spec.
>
> It's horrible practice to use it, too, since it could be a big upload
> that uses all your memory.
>
> What are you using that does request.body.to_s? Can you change it?
>
> --
> Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Problem with x-www-form-urlencoded
2010-07-15 22:30 0% ` Richard Penwell
@ 2010-07-15 22:40 3% ` Eric Wong
2010-07-15 23:49 0% ` Richard Penwell
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2010-07-15 22:40 UTC (permalink / raw)
To: unicorn list
Richard Penwell <almightylinuxgod@me.com> wrote:
> So I discovered this was a problem whereby request.body.to_s behaves
> differently. I wonder if TeeStream should define to_s as an alias for
> read?
to_s isn't defined by any version of the Rack spec.
It's horrible practice to use it, too, since it could be a big upload
that uses all your memory.
What are you using that does request.body.to_s? Can you change it?
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Problem with x-www-form-urlencoded
2010-07-15 22:14 3% ` Eric Wong
@ 2010-07-15 22:30 0% ` Richard Penwell
2010-07-15 22:40 3% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Richard Penwell @ 2010-07-15 22:30 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
So I discovered this was a problem whereby request.body.to_s behaves differently. I wonder if TeeStream should define to_s as an alias for read?
Sent from my iPhone
On Jul 15, 2010, at 6:14 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Richard Penwell <almightylinuxgod@me.com> wrote:
>> Howdy all,
>
>> I'm having a strange issue after moving from Thin to Unicon. One of
>> the form values being posted is not showing up in our request, below
>> you can see a Rails log entry and notice that there is no parameter
>> 'messageID' but it shows in the
>> 'action_dispatch.request.request_parameters' collection.
>
> Hi Richard, Which versions of Rails and Rack are you using?
>
> There's a chance Thin and Unicorn could be loading different
> versions of Rack and we might be hitting a bug in one version
> of Rack.
>
>> Has anyone else seen this, and is there a solution?
>
> I haven't seen nor looked into this myself, but I've heard some talk of
> multipart oddness in the Rack mailing list
>
> --
> Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Problem with x-www-form-urlencoded
2010-07-15 20:46 4% Problem with x-www-form-urlencoded Richard Penwell
@ 2010-07-15 22:14 3% ` Eric Wong
2010-07-15 22:30 0% ` Richard Penwell
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2010-07-15 22:14 UTC (permalink / raw)
To: unicorn list
Richard Penwell <almightylinuxgod@me.com> wrote:
> Howdy all,
> I'm having a strange issue after moving from Thin to Unicon. One of
> the form values being posted is not showing up in our request, below
> you can see a Rails log entry and notice that there is no parameter
> 'messageID' but it shows in the
> 'action_dispatch.request.request_parameters' collection.
Hi Richard, Which versions of Rails and Rack are you using?
There's a chance Thin and Unicorn could be loading different
versions of Rack and we might be hitting a bug in one version
of Rack.
> Has anyone else seen this, and is there a solution?
I haven't seen nor looked into this myself, but I've heard some talk of
multipart oddness in the Rack mailing list
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Problem with x-www-form-urlencoded
@ 2010-07-15 20:46 4% Richard Penwell
2010-07-15 22:14 3% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Richard Penwell @ 2010-07-15 20:46 UTC (permalink / raw)
To: mongrel-unicorn
Howdy all,
I'm having a strange issue after moving from Thin to Unicon. One of the form values being posted is not showing up in our request, below you can see a Rails log entry and notice that there is no parameter 'messageID' but it shows in the 'action_dispatch.request.request_parameters' collection.
Has anyone else seen this, and is there a solution?
Started POST "/smsGatewayClient/notifyMultimediaMessageDelivered" for 10.244.90.114 at Thu Jul 15 13:39:26 -0700 2010
Processing by MessagesController#discovered as */*
Parameters: {"deliveryResponse"=>"<?xml version=\"1.0\"?>\r\n<env:Envelope xmlns:env=\"http://schemas.xmlsoap.org/soap/envelope/\">\r\n<env:Header>\r\n<mm7:TransactionID xmlns:mm7=\"http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-4\" env:mustUnderstand=\"1\">0AB1A686B00E00002010000101</mm7:TransactionID>\r\n</env:Header>\r\n<env:Body>\r\n<DeliveryReportReq xmlns=\"http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-4\">\r\n<MM7Version>6.8.0</MM7Version>\r\n<MessageID>0AB1A686B00E000020100001</MessageID>\r\n<Recipient>\r\n<Number>6178331496</Number>\r\n</Recipient>\r\n<Sender>\r\n<ShortCode>78000</ShortCode>\r\n</Sender>\r\n<Date>2010-07-15T20:38:55+00:00</Date>\r\n<MMStatus>Retrieved</MMStatus>\r\n<UACapabilities UAProf=\"rim9530v1\"\r\n Ti
meStamp=\"2010-07-15T20:38:55+00:00\" />\r\n</DeliveryReportReq>\r\n</env:Body>\r\n</env:Envelope>", "destination"=>"tel:6178331496", "method"=>"post", "clientTransactionID"=>"21qb7g71m72i5l
21ks6t85q3t5sc\">", "serviceCode"=>"78000", "outputState"=>"C", "charset"=>"UTF-8\", \"SERVER_PROTOCOL\"=>\"HTTP/1.0\", \"action_dispatch.secret_token\"=>\"REDACTED\", \"rack.run_once\"=>false, \"rack.version\"=>[1, 1], \"SERVER_SOFTWARE\"=>\"Unicorn 1.1.2\", \"PATH_INFO\"=>\"/smsGatewayClient/notifyMultimediaMessageDelivered\", \"REMOTE_ADDR\"=>\"127.0.0.1\", \"action_dispatch.request.path_parameters\"=>{:action=>\"index\", :controller=>\"forward\", :url=>\"notifyMultimediaMessageDelivered\"}, \"SCRIPT_NAME\"=>\"\", \"action_dispatch.parameter_filter\"=>[:password], \"rack.multithread\"=>false, \"HTTP_VERSION\"=>\"HTTP/1.0\", \"action_dispatch.request.request_parameters\"=>{\"deliveryResponse\"=>\"<?xml version=\\\"1.0\\\"?>\\r\\n<env:Envelope xmlns:env=\\\"http://schemas.xmlsoap.org/soa
p/envelope/\\\">\\r\\n<env:Header>\\r\\n<mm7:TransactionID xmlns:mm7=\\\"http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-4\\\" env:mustUnderstand=\\\"1\\\">0AB1A686
B00E00002010000101</mm7:TransactionID>\\r\\n</env:Header>\\r\\n<env:Body>\\r\\n<DeliveryReportReq xmlns=\\\"http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-4\\\">\\r\\n<MM7Version>6.8.0</MM7Version>\\r\\n<MessageID>0AB1A686B00E000020100001</MessageID>\\r\\n<Recipient>\\r\\n<Number>6178331496</Number>\\r\\n</Recipient>\\r\\n<Sender>\\r\\n<ShortCode>78000</ShortCode>\\r\\n</Sender>\\r\\n<Date>2010-07-15T20:38:55 00:00</Date>\\r\\n<MMStatus>Retrieved</MMStatus>\\r\\n<UACapabilities UAProf=\\\"rim9530v1\\\"\\r\\n TimeStamp=\\\"2010-07-15T20:38:55 00:00\\\" />\\r\\n</DeliveryReportReq>\\r\\n</env:Body>\\r\\n</env:Envelope>\", \"messageID\"=>\"1s2oqbn15s4j3t2jbsgft72ijqh9\", \"destination\"=>\"tel:6178331496\", \"clientTransactionID\"=>\"21qb7g71m72i5l21ks6t85q3t5sc\",
\"serviceCode\"=>\"78000\", \"outputState\"=>\"C\"}, \"rack.request.form_vars\"=>\"messageID=1s2oqbn15s4j3t2jbsgft72ijqh9", "#<struct Unicorn::TeeInput socket"=>"nil, req={\"action_dispatch
.request.formats\"=>[#<Mime::Type:0xb7476474 @synonyms=[\"application/xhtml xml\"], @symbol=:html, @string=\"text/html\">], \"action_dispatch.request.parameters\"=>{\"deliveryResponse\"=>\"<?xml version=\\\"1.0\\\"?>\\r\\n<env:Envelope xmlns:env=\\\"http://schemas.xmlsoap.org/soap/envelope/\\\">\\r\\n<env:Header>\\r\\n<mm7:TransactionID xmlns:mm7=\\\"http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-4\\\" env:mustUnderstand=\\\"1\\\">0AB1A686B00E00002010000101</mm7:TransactionID>\\r\\n</env:Header>\\r\\n<env:Body>\\r\\n<DeliveryReportReq xmlns=\\\"http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-4\\\">\\r\\n<MM7Version>6.8.0</MM7Version>\\r\\n<MessageID>0AB1A686B00E000020100001</MessageID>\\r\\n<Recipient>\\r\\n<Number>6178331496</Number>\\
r\\n</Recipient>\\r\\n<Sender>\\r\\n<ShortCode>78000</ShortCode>\\r\\n</Sender>\\r\\n<Date>2010-07-15T20:38:55 00:00</Date>\\r\\n<MMStatus>Retrieved</MMStatus>\\r\\n<UACapabilities UAProf=\\
\"rim9530v1\\\"\\r\\n TimeStamp=\\\"2010-07-15T20:38:55 00:00\\\" />\\r\\n</DeliveryReportReq>\\r\\n</env:Body>\\r\\n</env:Envelope>\", \"messageID\"=>\"1s2oqbn15s4j3t2jbsgft72ijqh9\", \"destination\"=>\"tel:6178331496\", \"sender\"=>\"6178331496\", \"action\"=>\"index\", \"url\"=>\"notifyMultimediaMessageDelivered\", \"clientTransactionID\"=>\"21qb7g71m72i5l21ks6t85q3t5sc\", \"serviceCode\"=>\"78000\", \"outputState\"=>\"C\", \"controller\"=>\"forward\"}, \"rack.session\"=>{\"session_id\"=>\"b059b627561cc047dd7ab3e7e8de0baf\"}, \"rack.logger\"=>#<Logger:0xb7a21590 @logdev=#<Logger::LogDevice:0xb7a214dc @shift_age=0, @filename=\"log/unicorn.log\", @mutex=#<Logger::LogDevice::LogDeviceMutex:0xb7a214b4 @mon_waiting_queue=[], @mon_entering_queue=[], @mon_count=0, @mon_owner=nil>, @dev=#<File
:log/unicorn.log>, @shift_size=1048576>, @formatter=#<Logger::SimpleFormatter:0xb6f3bcfc @datetime_format=nil>, @level=0, @default_formatter=#<Logger::Formatter:0xb7a21504 @datetime_format=n
il>, @progname=nil>, \"SERVER_NAME\"=>\"cdngw.g8wave.com\", \"HTTP_HOST\"=>\"cdngw.g8wave.com\", \"action_dispatch.remote_ip\"=>#<ActionDispatch::RemoteIp::RemoteIpGetter:0xb703cb74 @trusted_proxies=/(^127\\.0\\.0\\.1$|^(10|172\\.(1[6-9]|2[0-9]|30|31)|192\\.168)\\.)/i, @check_ip_spoofing=true, @env={...}>, \"rack.url_scheme\"=>\"http\", \"CONTENT_LENGTH\"=>\"1332\", \"HTTP_USER_AGENT\"=>\"Jakarta Commons-HttpClient/3.0\", \"HTTP_X_REAL_IP\"=>\"10.244.90.114\", \"REQUEST_PATH\"=>\"/smsGatewayClient/notifyMultimediaMessageDelivered\", \"action_dispatch.request.query_parameters\"=>{\"sender\"=>\"6178331496\"}, \"rack.errors\"=>#<File:log/unicorn.stderr.log>, \"CONTENT_TYPE\"=>\"application/x-www-form-urlencoded"}
Eternally grateful,
R
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 4%]
* Re: [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks
2010-07-14 2:34 0% ` Eric Wong
@ 2010-07-14 7:00 0% ` Lawrence Pit
0 siblings, 1 reply; 200+ results
From: Lawrence Pit @ 2010-07-14 7:00 UTC (permalink / raw)
To: unicorn list
>> I need to play a bit more with this.. I'll probably have to change my
>> /etc/init.d/unicorn script so that it starts with the
>> vendor/bundler_gems version instead of a system-wide version :o I'll
>> get back to you..
>>
>
> Take a look at http://unicorn.bogomips.org/Sandbox.html According to
> Jamie, using "bundle exec unicorn_rails" is the correct way to go.
>
Thanks. Yes indeed, bundle exec is the way to go. I've got it rolling
back nicely now.
It appears unicorn rolls back by itself when it can't start the new
master. Nice!
Jamie also mentions to use the shared vendor/bundler_gems path. Though
I do use that in all my projects I'm not so sure it's wise to do when
you can't afford any downtime. I'll have to wait for unicorn v1.1.3
before I can test whether rolling back will indeed continue with unicorn
v1.1.2 instead of v1.1.3 ;o
Cheers,
Lawrence
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks
2010-07-14 2:14 5% ` Lawrence Pit
@ 2010-07-14 2:34 0% ` Eric Wong
2010-07-14 7:00 0% ` Lawrence Pit
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2010-07-14 2:34 UTC (permalink / raw)
To: unicorn list
Lawrence Pit <lawrence.pit@gmail.com> wrote:
> Hi Eric,
>
> At the top of my pastie http://pastie.org/1043347.txt you can see that
> when I request of list of gems it mentions only unicorn v1.1.2
>
> I also added the suggested logging to the before_fork block and I also
> logged the unicorn version. Interesting output. First it runs the master
> with Unicorn v1.1.2. But when I send a USR2 it exec'ed with a Unicorn
> v1.1.1 for the new master. So yes, I still had a version lying around,
> namely in the $APP_ROOT/vendor/bundler_gems dir.
>
> See also: http://pastie.org/1043487.txt
>
> It does do this though after a USR2:
>
> executing ["/usr/local/rvm/gems/ree-1.8.7-2010.02/bin/unicorn_rails",
> "-D", "-E", "staging", "-c",
> "/var/www/staging/current/config/unicorn/staging.rb"]
>
> I.e., it tries to exec exactly how I start unicorn. That unicorn_rails
> binary in that path is definitely v1.1.2. So I don't quite understand
> why the reexeced one is picking the version from the vendor/bundler_gems
> dir.
It's probably loading 1.1.1 because of GEM_HOME/GEM_PATH being set. The
"unicorn_rails"/"unicorn" wrappers just activates whatever gems it sees,
and GEM_HOME/GEM_PATH can influence the wrapper.
Managing RubyGems installations is still tricky :<
> I need to play a bit more with this.. I'll probably have to change my
> /etc/init.d/unicorn script so that it starts with the
> vendor/bundler_gems version instead of a system-wide version :o I'll
> get back to you..
Take a look at http://unicorn.bogomips.org/Sandbox.html According to
Jamie, using "bundle exec unicorn_rails" is the correct way to go.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks
2010-07-14 0:38 3% ` Eric Wong
@ 2010-07-14 2:14 5% ` Lawrence Pit
2010-07-14 2:34 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Lawrence Pit @ 2010-07-14 2:14 UTC (permalink / raw)
To: unicorn list
Hi Eric,
At the top of my pastie http://pastie.org/1043347.txt you can see that
when I request of list of gems it mentions only unicorn v1.1.2
I also added the suggested logging to the before_fork block and I also
logged the unicorn version. Interesting output. First it runs the master
with Unicorn v1.1.2. But when I send a USR2 it exec'ed with a Unicorn
v1.1.1 for the new master. So yes, I still had a version lying around,
namely in the $APP_ROOT/vendor/bundler_gems dir.
See also: http://pastie.org/1043487.txt
It does do this though after a USR2:
executing ["/usr/local/rvm/gems/ree-1.8.7-2010.02/bin/unicorn_rails",
"-D", "-E", "staging", "-c",
"/var/www/staging/current/config/unicorn/staging.rb"]
I.e., it tries to exec exactly how I start unicorn. That unicorn_rails
binary in that path is definitely v1.1.2. So I don't quite understand
why the reexeced one is picking the version from the vendor/bundler_gems
dir.
I need to play a bit more with this.. I'll probably have to change my
/etc/init.d/unicorn script so that it starts with the
vendor/bundler_gems version instead of a system-wide version :o I'll
get back to you..
Cheers,
Lawrence
> Lawrence Pit <lawrence.pit@gmail.com> wrote:
>
>> Hi Eric,
>>
>> Thanks mate. Unfortunately this still doesn't seem to work for me.
>>
>> I went through the process manually, you can see a transcript at
>> http://pastie.org/1043347.txt
>> The indented text is what I see appearing in the unicorn stderr.log.
>>
>
> Thanks Lawrence, the following line looks suspicious to me:
>
> reaped #<Process::Status: pid=4382,exited(0)> exec()-ed
>
> Which makes it seem like
> http://git.bogomips.org/cgit/unicorn.git/commit/?id=3f0f9d6 didn't get
> applied (and I just checked the 1.1.2 gem and it looks good to me)
>
> Can you dump out the ENV hash in your before_exec hook of your
> unicorn.conf.rb? I'm wondering if GEM_HOME or GEM_PATH is set
> and doing anything funky, causing you to load an old version
> of Unicorn:
>
> before_exec do |server|
> ENV.each do |key,value|
> server.logger.info "#{key}=#{value}"
> end
> end
>
>
>> As you can see it reports two errors during the process, saying
>> unicorn.pid is stale.
>>
>> I wonder whether this is because in my unicorn config file I mention:
>>
>> pid "/var/www/staging/current/tmp/pids/unicorn.pid"
>>
>> whereas in your back_out_of_upgrade test you don't have such a line?
>>
>
> It does, I create a similar line in the unicorn_setup() function of
> test-lib.sh
>
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 5%]
* Re: [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks
@ 2010-07-14 0:38 3% ` Eric Wong
2010-07-14 2:14 5% ` Lawrence Pit
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2010-07-14 0:38 UTC (permalink / raw)
To: unicorn list
Lawrence Pit <lawrence.pit@gmail.com> wrote:
> Hi Eric,
>
> Thanks mate. Unfortunately this still doesn't seem to work for me.
>
> I went through the process manually, you can see a transcript at
> http://pastie.org/1043347.txt
> The indented text is what I see appearing in the unicorn stderr.log.
Thanks Lawrence, the following line looks suspicious to me:
reaped #<Process::Status: pid=4382,exited(0)> exec()-ed
Which makes it seem like
http://git.bogomips.org/cgit/unicorn.git/commit/?id=3f0f9d6 didn't get
applied (and I just checked the 1.1.2 gem and it looks good to me)
Can you dump out the ENV hash in your before_exec hook of your
unicorn.conf.rb? I'm wondering if GEM_HOME or GEM_PATH is set
and doing anything funky, causing you to load an old version
of Unicorn:
before_exec do |server|
ENV.each do |key,value|
server.logger.info "#{key}=#{value}"
end
end
> As you can see it reports two errors during the process, saying
> unicorn.pid is stale.
>
> I wonder whether this is because in my unicorn config file I mention:
>
> pid "/var/www/staging/current/tmp/pids/unicorn.pid"
>
> whereas in your back_out_of_upgrade test you don't have such a line?
It does, I create a similar line in the unicorn_setup() function of
test-lib.sh
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: SIGWINCH
@ 2010-07-13 8:24 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-07-13 8:24 UTC (permalink / raw)
To: unicorn list
Lawrence Pit <lawrence.pit@gmail.com> wrote:
> Hi,
>
> I followed the procedure to replace a running unicorn. Works fine,
> except for one thing: after I decide to back out, ie I send a HUP to the
> old master followed by a QUIT to the new master, then:
Ah, ok. I can reproduce it. The problem is the HUP by the old
master tries to reset the pid file to the non-"oldbin" version
which the new master is still holding on to.
You could QUIT the new master first and then HUP, but this is _far_ from
ideal because it leaves you with a window without running workers (and
also it contradicts our documentation). It's also difficult to avoid
race conditions this way.
I'm looking for a better way to go about this, pid files are nasty :x
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* test failure on Mac OSX
@ 2010-06-25 15:06 2% Andrew Milkowski
0 siblings, 0 replies; 200+ results
From: Andrew Milkowski @ 2010-06-25 15:06 UTC (permalink / raw)
To: mongrel-unicorn
Hi there,
ran to a snag building unicorn from sources (git master at
git://git.bogomips.org/unicorn.git)
1) Failure:
: test_working_directory_rel_path_config_file(ExecTest)
[test/exec/test_exec.rb:106]:
: <"/var/folders/gy/gyjECZCGGxKv3I3mRTmhB++++TI/-Tmp-/unicorn_exec_test20100625-1679-1x3ks9d-0">
expected but was
: <"/private/var/folders/gy/gyjECZCGGxKv3I3mRTmhB++++TI/-Tmp-/unicorn_exec_test20100625-1679-1x3ks9d-0">.
:
: 1 tests, 2 assertions, 1 failures, 0 errors
make: *** [test/exec/test_exec.rb--test_working_directory_rel_path_config_file.n]
Error 1
running following configuration (session console dump below)
bash-3.2$ uname -v
Darwin Kernel Version 10.4.0: Fri Apr 23 18:27:12 PDT 2010;
root:xnu-1504.7.4~1/RELEASE_X86_64
bash-3.2$ ruby -v
ruby 1.8.7 (2009-12-24 patchlevel 248) [i686-darwin10.2.0], MBARI
0x6770, Ruby Enterprise Edition 2010.01
bash-3.2$
thanks in advance!
bash-3.2$ make
* test/unit/test_configurator.rb
* test/unit/test_http_parser.rb
* test/unit/test_http_parser_ng.rb
* test/unit/test_request.rb
* test/unit/test_response.rb
* test/unit/test_socket_helper.rb
* test/unit/test_tee_input.rb
* test/unit/test_util.rb
* test/unit/test_server.rb -n test_preload_app_config
* test/unit/test_server.rb -n test_broken_app
* test/unit/test_server.rb -n test_simple_server
* test/unit/test_server.rb -n test_client_shutdown_writes
* test/unit/test_server.rb -n test_client_shutdown_write_truncates
* test/unit/test_server.rb -n test_client_malformed_body
* test/unit/test_server.rb -n test_trickle_attack
* test/unit/test_server.rb -n test_close_client
* test/unit/test_server.rb -n test_bad_client
* test/unit/test_server.rb -n test_logger_set
* test/unit/test_server.rb -n test_logger_changed
* test/unit/test_server.rb -n test_bad_client_400
* test/unit/test_server.rb -n test_http_0_9
* test/unit/test_server.rb -n test_header_is_too_long
* test/unit/test_server.rb -n test_file_streamed_request
* test/unit/test_server.rb -n test_file_streamed_request_bad_body
* test/unit/test_server.rb -n test_listener_names
* test/exec/test_exec.rb -n test_working_directory_rel_path_config_file
: /opt/local/src/ruby-enterprise-server/ruby-enterprise-1.8.7-2010.01/build/lib/ruby/1.8/pathname.rb:263:
warning: `*' interpreted as argument prefix
: Loaded suite test/exec/test_exec
: Started
: test_working_directory_rel_path_config_file(ExecTest): F
:
: Finished in 0.629278 seconds.
:
: 1) Failure:
: test_working_directory_rel_path_config_file(ExecTest)
[test/exec/test_exec.rb:106]:
: <"/var/folders/gy/gyjECZCGGxKv3I3mRTmhB++++TI/-Tmp-/unicorn_exec_test20100625-1679-1x3ks9d-0">
expected but was
: <"/private/var/folders/gy/gyjECZCGGxKv3I3mRTmhB++++TI/-Tmp-/unicorn_exec_test20100625-1679-1x3ks9d-0">.
:
: 1 tests, 2 assertions, 1 failures, 0 errors
make: *** [test/exec/test_exec.rb--test_working_directory_rel_path_config_file.n]
Error 1
bash-3.2$
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: Unicorn future plans
2010-06-14 20:58 2% ` John-Paul Bader
@ 2010-06-14 22:10 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-06-14 22:10 UTC (permalink / raw)
To: unicorn list
John-Paul Bader <hukl@berlin.ccc.de> wrote:
> Hey,
>
> your plans sound great except for ignoring FreeBSD ;)
>
> Seriously many many Servers, including many which I administrate run
> on FreeBSD and they do so very well. I'm not very familiar with the
> internals of the FreeBSD Kernel but I can assure you that it runs
> perfectly on 8 and 16 core machines and I would extremely happy if I
> could continue to use unicorn on them.
Hi John-Paul,
Reread my post carefully, not much is changing for 8-16 core users.
FreeBSD and SMP will continue to be supported. I wasn't referring
to SMP at all when I was talking about Linux-only bits.
> It should be easier to maintain a FreeBSD version as they (FreeBSD
> developers) tend to aim for more consistency across releases than
> Linux. You said once that you don't run any BSD machines but I'd be
> happy to offer you access to one of my BSD servers for testing.
Thanks for the offer. I'll keep it in mind if I need it again.
> Furthermore since Mac OS X and FreeBSD share many features like kqueue
> and many Ruby developers are running macs it would make even more
> sense to at least care about BSD even if its not you primary platform.
I know, I've fixed some things on OSX platforms via FreeBSD (OSX scares
me with its GUI-ness). Keep in mind kqueue (and epoll) are worthless
for Unicorn itself since Unicorn only handles one client at a time.
However, Rainbows! can already use kqueue/epoll with EventMachine and
Rev.
> I don't want to start a flame war or say that one OS is better than
> another. Linux is certainly great but so is FreeBSD. For the SMP part
> I recommend the following page on freebsd.org:
Again, I wasn't talking about SMP at all. SMP works fine on current
Unicorn and mid-sized servers. When going to more cores, SMP itself
is a bottleneck, not the kernel.
With Unicorn 2.x, I'm targeting NUMA hardware that isn't available in
commodity servers yet. Currently, NUMA makes _zero_ sense in web
application servers, but in case things change in a few years, we'll be
ready.
It may be a chicken-and-egg problem, too. Hardware manufacturers are
slow to commoditize NUMA because a good chunk of software can't even
utilize SMP effectively :)
> To conclude I can only say that I'm running unicorn on several FreeBSD
> hosts and so far I couldn't be happier with it. As stated before, I'd
> be more than happy to continue using that setup.
Again, don't worry :) You'll be able to continue using everything
as-is.
> Kindest regards and thanks for all you efforts,
No problem. Please don't top post in the future.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Unicorn future plans
@ 2010-06-14 20:58 2% ` John-Paul Bader
2010-06-14 22:10 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: John-Paul Bader @ 2010-06-14 20:58 UTC (permalink / raw)
To: unicorn list
Hey,
your plans sound great except for ignoring FreeBSD ;)
Seriously many many Servers, including many which I administrate run on FreeBSD and they do so very well. I'm not very familiar with the internals of the FreeBSD Kernel but I can assure you that it runs perfectly on 8 and 16 core machines and I would extremely happy if I could continue to use unicorn on them.
It should be easier to maintain a FreeBSD version as they (FreeBSD developers) tend to aim for more consistency across releases than Linux. You said once that you don't run any BSD machines but I'd be happy to offer you access to one of my BSD servers for testing.
Furthermore since Mac OS X and FreeBSD share many features like kqueue and many Ruby developers are running macs it would make even more sense to at least care about BSD even if its not you primary platform.
I don't want to start a flame war or say that one OS is better than another. Linux is certainly great but so is FreeBSD. For the SMP part I recommend the following page on freebsd.org:
http://www.freebsd.org/smp/
And maybe specifically:
http://www.freebsd.org/smp/#resources
To conclude I can only say that I'm running unicorn on several FreeBSD hosts and so far I couldn't be happier with it. As stated before, I'd be more than happy to continue using that setup.
Kindest regards and thanks for all you efforts,
John
On 14.06.2010, at 21:46, Eric Wong wrote:
> Hi all,
>
> Some of you are wondering about the future of the project, especially
> since we're nearing a 1.0 release.
>
> == 1.x - bugfixes and Rack-compatibility synchronization
>
> The 1.x series will focus mainly on bug fixes and compatibility with
> Rack as it evolves.
>
> If Rack drops the rewindability requirement of "rack.input", Unicorn
> will follow ASAP and allow TeeInput to be optional middleware with
> newer Rack versions.
>
> Rubinius should be fully-supported soon, as it's already mostly working
> except for a few corner-case things Rubinius doesn't implement (issues
> filed on their bug tracker).
>
> == 2.x - the fun and crazy stuff
>
> First off, there'll be internal API cleanups + sync with
> Rainbows!/Zbatery This won't be user visible, but it'll be less ugly
> inside.
>
> === Scalability improvements
>
> I don't know if we'll see hundreds/thousands of CPUs in a single
> application server any time soon, but 2.x will have internal changes
> that'll make us more ready for that. It could be 5-10 years before
> massively multi-core machines are viable for web apps, but it'd
> certainly be fun to max out Unicorn on those.
>
> I'll be less shy about sacrificing portability for massive scalability.
> Correct me if I'm wrong, but Linux is the only Free kernel that scales
> to monster multicore machines right now, so I'll primarily focus on
> working with features in Linux.
>
> Currently, 8-16 cores seems to be the sweet spot (and has been for a
> while), and present-day Unicorn handles that fine as-is.
>
> === Features (for Rainbows!, mainly)
>
> IPv6 support and SSL will come, too. These features will mainly be to
> support Rainbows!, though some LANs could benefit from those, too. I'll
> have to review the MRI code for those, but I'm leaning towards only
> these new features under 1.9.2+.
>
> Multi-VM (MVM, Ruby 1.9 experimental branch) support will probably
> happen only in Rainbows! rather than Unicorn. A true fork() is still
> safer in the event of a crash (but less memory-efficient).
>
> == Miscellaneous
>
> I have no plans to provide commercial support, but I'll continue
> offering free support on the mailing list (or private email if you're
> shy).
>
> As some of you may have noticed; I don't endorse commercial products or
> services at all. This won't change. However, there will probably be
> more commercial support available from 3rd parties after a 1.0 release.
>
>
> Thanks for reading!
>
> --
> Eric Wong
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: Working directory and config.ru
@ 2010-06-10 9:58 5% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-06-10 9:58 UTC (permalink / raw)
To: unicorn list
Eric Wong <normalperson@yhbt.net> wrote:
> Pierre Baillet <oct@fotonauts.com> wrote:
> > Hi,
> >
> > I naively expected unicorn to honor the working_directory
> > configuration directive before attempting to locate the config.ru but
> > this does not seem to be the case. Is this behavior wanted ? From the
> > code, I can guess that the configuration file parsing is done much
> > later than the current config.ru location attempt.
>
> Hi Pierre,
>
> Oops, definitely not wanted behavior. Unicorn should honor
> working_directory with regard to config.ru. I'll start working
> on a fix shortly, thanks for the report!
I just pushed the following out with a few other cleanups.
Maintaining Rainbows!/Zbatery compatibility was a bit costly in terms of
prettiness.
Overall, my initial hesitation to support "working_directory" last year
was validated by the complexity of maintaining relative path
compatibility across the board.
I'm very glad for the integration test suite (stolen from Rainbows!)
which allows me to write tests in my "native" language :>
There'll be more tests coming when I'm more awake (and I'm actually
developing a real Rack application which will be public Real Soon
Now(TM), but more targeted at Rainbows!/Zbatery :)
>From 4accf4449390c649bce0b1c9d84314d65fd41f8e Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Thu, 10 Jun 2010 08:47:10 +0000
Subject: [PATCH] respect "working_directory" wrt config.ru
Since we added support for the "working_directory" parameter, it
often became unclear where/when certain paths would be bound.
There are some extremely nasty dependencies and ordering issues
when doing this. It's all pretty fragile, but works for now
and we even have a full integration test to keep it working.
I plan on cleaning this up 2.x.x to be less offensive to look
at (Rainbows! and Zbatery are a bit tied to this at the moment).
Thanks to Pierre Baillet for reporting this.
ref: http://mid.gmane.org/AANLkTimKb7JARr_69nfVrJLvMZH3Gvs1o_KwZFLKfuxy@mail.gmail.com
---
bin/unicorn | 5 +---
bin/unicorn_rails | 17 +++++++++---
lib/unicorn.rb | 7 ++---
lib/unicorn/configurator.rb | 56 ++++++++++++++++++++++++++++++++++++++++++
lib/unicorn/launcher.rb | 5 ++-
t/t0003-working_directory.sh | 53 +++++++++++++++++++++++++++++++++++++++
6 files changed, 129 insertions(+), 14 deletions(-)
create mode 100755 t/t0003-working_directory.sh
diff --git a/bin/unicorn b/bin/unicorn
index beece97..2cc10b1 100755
--- a/bin/unicorn
+++ b/bin/unicorn
@@ -107,10 +107,7 @@ opts = OptionParser.new("", 24, ' ') do |opts|
opts.parse! ARGV
end
-ru = ARGV[0] || "config.ru"
-abort "configuration file #{ru} not found" unless File.exist?(ru)
-
-app = Unicorn.builder(ru, opts)
+app = Unicorn.builder(ARGV[0] || 'config.ru', opts)
options[:listeners] << "#{host}:#{port}" if set_listener
if $DEBUG
diff --git a/bin/unicorn_rails b/bin/unicorn_rails
index 2f88bc1..e9cac00 100755
--- a/bin/unicorn_rails
+++ b/bin/unicorn_rails
@@ -107,8 +107,6 @@ opts = OptionParser.new("", 24, ' ') do |opts|
opts.parse! ARGV
end
-ru = ARGV[0] || (File.exist?('config.ru') ? 'config.ru' : nil)
-
def rails_dispatcher
if ::Rails::VERSION::MAJOR >= 3 && ::File.exist?('config/application.rb')
if ::File.read('config/application.rb') =~ /^module\s+([\w:]+)\s*$/
@@ -127,9 +125,20 @@ def rails_dispatcher
result || abort("Unable to locate the application dispatcher class")
end
-def rails_builder(daemonize)
+def rails_builder(ru, opts, daemonize)
+ return Unicorn.builder(ru, opts) if ru
+
+ # allow Configurator to parse cli switches embedded in the ru file
+ Unicorn::Configurator::RACKUP.update(:file => :rails, :optparse => opts)
+
# this lambda won't run until after forking if preload_app is false
+ # this runs after config file reloading
lambda do ||
+ # Rails 3 includes a config.ru, use it if we find it after
+ # working_directory is bound.
+ ::File.exist?('config.ru') and
+ return Unicorn.builder('config.ru', opts).call
+
# Load Rails and (possibly) the private version of Rack it bundles.
begin
require ::File.expand_path('config/boot')
@@ -179,7 +188,7 @@ def rails_builder(daemonize)
end
end
-app = ru ? Unicorn.builder(ru, opts) : rails_builder(daemonize)
+app = rails_builder(ARGV[0], opts, daemonize)
options[:listeners] << "#{host}:#{port}" if set_listener
if $DEBUG
diff --git a/lib/unicorn.rb b/lib/unicorn.rb
index c026236..a7b0646 100644
--- a/lib/unicorn.rb
+++ b/lib/unicorn.rb
@@ -33,11 +33,10 @@ module Unicorn
# Unicorn config). The returned lambda will be called when it is
# time to build the app.
def builder(ru, opts)
- if ru =~ /\.ru\z/
- # parse embedded command-line options in config.ru comments
- /^#\\(.*)/ =~ File.read(ru) and opts.parse!($1.split(/\s+/))
- end
+ # allow Configurator to parse cli switches embedded in the ru file
+ Unicorn::Configurator::RACKUP.update(:file => ru, :optparse => opts)
+ # always called after config file parsing, may be called after forking
lambda do ||
inner_app = case ru
when /\.ru$/
diff --git a/lib/unicorn/configurator.rb b/lib/unicorn/configurator.rb
index e4305c2..0716e64 100644
--- a/lib/unicorn/configurator.rb
+++ b/lib/unicorn/configurator.rb
@@ -13,6 +13,12 @@ module Unicorn
# nginx is also available at
# http://unicorn.bogomips.org/examples/nginx.conf
class Configurator < Struct.new(:set, :config_file, :after_reload)
+ # :stopdoc:
+ # used to stash stuff for deferred processing of cli options in
+ # config.ru after "working_directory" is bound. Do not rely on
+ # this being around later on...
+ RACKUP = {}
+ # :startdoc:
# Default settings for Unicorn
DEFAULTS = {
@@ -51,6 +57,8 @@ module Unicorn
def reload #:nodoc:
instance_eval(File.read(config_file), config_file) if config_file
+ parse_rackup_file
+
# working_directory binds immediately (easier error checking that way),
# now ensure any paths we changed are correctly set.
[ :pid, :stderr_path, :stdout_path ].each do |var|
@@ -66,6 +74,9 @@ module Unicorn
def commit!(server, options = {}) #:nodoc:
skip = options[:skip] || []
+ if ready_pipe = RACKUP.delete(:ready_pipe)
+ server.ready_pipe = ready_pipe
+ end
set.each do |key, value|
value == :unset and next
skip.include?(key) and next
@@ -411,5 +422,50 @@ module Unicorn
set[var] = my_proc
end
+ # this is called _after_ working_directory is bound. This only
+ # parses the embedded switches in .ru files
+ # (for "rackup" compatibility)
+ def parse_rackup_file # :nodoc:
+ ru = RACKUP[:file] or return # we only return here in unit tests
+
+ # :rails means use (old) Rails autodetect
+ if ru == :rails
+ File.readable?('config.ru') or return
+ ru = 'config.ru'
+ end
+
+ File.readable?(ru) or
+ raise ArgumentError, "rackup file (#{ru}) not readable"
+
+ # it could be a .rb file, too, we don't parse those manually
+ ru =~ /\.ru\z/ or return
+
+ /^#\\(.*)/ =~ File.read(ru) or return
+ warn "ru cli opts: #{$1}"
+ RACKUP[:optparse].parse!($1.split(/\s+/))
+
+ # XXX ugly as hell, WILL FIX in 2.x (along with Rainbows!/Zbatery)
+ host, port, set_listener, options, daemonize =
+ eval("[ host, port, set_listener, options, daemonize ]",
+ TOPLEVEL_BINDING)
+
+ warn [ :host, :port, :set_listener, :options, :daemonize ].inspect
+ warn [ ru, host, port, set_listener, options, daemonize ].inspect
+ # XXX duplicate code from bin/unicorn{,_rails}
+ set[:listeners] << "#{host}:#{port}" if set_listener
+
+ if daemonize
+ # unicorn_rails wants a default pid path, (not plain 'unicorn')
+ if ru == :rails
+ spid = set[:pid]
+ pid('tmp/pids/unicorn.pid') if spid.nil? || spid == :unset
+ end
+ unless RACKUP[:daemonized]
+ Unicorn::Launcher.daemonize!(options)
+ RACKUP[:ready_pipe] = options.delete(:ready_pipe)
+ end
+ end
+ end
+
end
end
diff --git a/lib/unicorn/launcher.rb b/lib/unicorn/launcher.rb
index 5ab04c7..7f3ffa6 100644
--- a/lib/unicorn/launcher.rb
+++ b/lib/unicorn/launcher.rb
@@ -56,8 +56,9 @@ class Unicorn::Launcher
end
end
# $stderr/$stderr can/will be redirected separately in the Unicorn config
- Unicorn::Configurator::DEFAULTS[:stderr_path] = "/dev/null"
- Unicorn::Configurator::DEFAULTS[:stdout_path] = "/dev/null"
+ Unicorn::Configurator::DEFAULTS[:stderr_path] ||= "/dev/null"
+ Unicorn::Configurator::DEFAULTS[:stdout_path] ||= "/dev/null"
+ Unicorn::Configurator::RACKUP[:daemonized] = true
end
end
diff --git a/t/t0003-working_directory.sh b/t/t0003-working_directory.sh
new file mode 100755
index 0000000..3faa6c0
--- /dev/null
+++ b/t/t0003-working_directory.sh
@@ -0,0 +1,53 @@
+#!/bin/sh
+. ./test-lib.sh
+t_plan 4 "config.ru inside alt working_directory"
+
+t_begin "setup and start" && {
+ unicorn_setup
+ rtmpfiles unicorn_config_tmp
+ rm -rf $t_pfx.app
+ mkdir $t_pfx.app
+
+ port=$(expr $listen : '[^:]*:\([0-9]\+\)')
+ host=$(expr $listen : '\([^:]*\):[0-9]\+')
+
+ cat > $t_pfx.app/config.ru <<EOF
+#\--daemonize --host $host --port $port
+use Rack::ContentLength
+use Rack::ContentType, "text/plain"
+run lambda { |env| [ 200, {}, [ "#{\$master_ppid}\\n" ] ] }
+EOF
+ # we have --host/--port in config.ru instead
+ grep -v ^listen $unicorn_config > $unicorn_config_tmp
+
+ # the whole point of this exercise
+ echo "working_directory '$t_pfx.app'" >> $unicorn_config_tmp
+
+ # allows ppid to be 1 in before_fork
+ echo "preload_app true" >> $unicorn_config_tmp
+ cat >> $unicorn_config_tmp <<\EOF
+before_fork do |server,worker|
+ $master_ppid = Process.ppid # should be zero to detect daemonization
+end
+EOF
+
+ mv $unicorn_config_tmp $unicorn_config
+
+ # rely on --daemonize switch, no & or -D
+ unicorn -c $unicorn_config
+ unicorn_wait_start
+}
+
+t_begin "hit with curl" && {
+ body=$(curl -sSf http://$listen/)
+}
+
+t_begin "killing succeeds" && {
+ kill $unicorn_pid
+}
+
+t_begin "response body ppid == 1 (daemonized)" && {
+ test "$body" -eq 1
+}
+
+t_done
--
Eric Wong (7):
launcher: get rid of backwards compatibility code
isolate: don't run isolate in parallel
Rakefile: only try rake-compiler if VERSION is defined
Rakefile: isolate to rbx directory
tests: set NO_PROXY when running tests
unicorn_rails: use Kernel#warn instead of $stderr.puts
respect "working_directory" wrt config.ru
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 5%]
* Re: unicorn_rails cleanup (possible fix for Rails3) pushed
2010-06-08 19:20 7% ` Eric Wong
@ 2010-06-08 19:25 0% ` Hongli Lai
0 siblings, 0 replies; 200+ results
From: Hongli Lai @ 2010-06-08 19:25 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
On Tue, Jun 8, 2010 at 9:20 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Thanks Hongli, so this only affects people who remove the
> config.ru that Rails 3 creates for them? Yikes...
No. The problem even occurs if you already have config.ru. But the
thing is, Rails 3 has deprecated ActionController::Dispatcher a few
weeks ago and replaced it with a stub. Rails::Rack::Static changed its
interface and must be constructed differently. The only way to obtain
a valid Rack endpoint for the app seems to be parsing
config/application.rb
> A few comments:
>
> + if ::Rails::VERSION::MAJOR >= 3 && ::File.exist?('config/application.rb')
> + ::File.read('config/application.rb') =~ /^module (.+)$/
>
> Maybe a more flexible regexp like this: /^module\s+([\w:]+)\s*$/ (or
> maybe even starting with: "^\s*") would be more reliable for folks who
> leave extra spaces around.
I think it's easier to just call 'strip'. :)
> Unfortunately, Ruby is not Python :)
>
> @@ -148,9 +167,9 @@ def rails_builder(daemonize)
> else
> use Rails::Rack::LogTailer unless daemonize
> use Rails::Rack::Debugger if $DEBUG
> + use Rails::Rack::Static, map_path
> map(map_path) do
> - use Rails::Rack::Static
> - run ActionController::Dispatcher.new
> + run rails_dispatcher
>
> Changing the call to use Rails::Rack::Static there is wrong. map_path
> is the URI prefix (RAILS_RELATIVE_URL_ROOT) and not the static file
> path we serve from. It appears the deprecation in Rails 3 broke some
> things and ActionDispatch::Static is configured slightly differently.
>
> Let me know if the edited patch below looks alright to you.
Yes it looks fine. A bit overcomplicated regexp compared to using
'strip' but whatever works. :)
With kind regards,
Hongli Lai
--
Phusion | The Computer Science Company
Web: http://www.phusion.nl/
E-mail: info@phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: unicorn_rails cleanup (possible fix for Rails3) pushed
@ 2010-06-08 19:20 7% ` Eric Wong
2010-06-08 19:25 0% ` Hongli Lai
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2010-06-08 19:20 UTC (permalink / raw)
To: unicorn list; +Cc: Hongli Lai
Hongli Lai <hongli@phusion.nl> wrote:
> Hi Eric.
>
> It would appear that recent Rails 3 changes have broken unicorn_rails,
> just like they broke Phusion Passenger. Here's a patch which fixes the
> problem.
> http://gist.github.com/429944
Thanks Hongli, so this only affects people who remove the
config.ru that Rails 3 creates for them? Yikes...
A few comments:
+ if ::Rails::VERSION::MAJOR >= 3 && ::File.exist?('config/application.rb')
+ ::File.read('config/application.rb') =~ /^module (.+)$/
Maybe a more flexible regexp like this: /^module\s+([\w:]+)\s*$/ (or
maybe even starting with: "^\s*") would be more reliable for folks who
leave extra spaces around.
Unfortunately, Ruby is not Python :)
@@ -148,9 +167,9 @@ def rails_builder(daemonize)
else
use Rails::Rack::LogTailer unless daemonize
use Rails::Rack::Debugger if $DEBUG
+ use Rails::Rack::Static, map_path
map(map_path) do
- use Rails::Rack::Static
- run ActionController::Dispatcher.new
+ run rails_dispatcher
Changing the call to use Rails::Rack::Static there is wrong. map_path
is the URI prefix (RAILS_RELATIVE_URL_ROOT) and not the static file
path we serve from. It appears the deprecation in Rails 3 broke some
things and ActionDispatch::Static is configured slightly differently.
Let me know if the edited patch below looks alright to you.
I'll also push out a few Rails 3 tests that exercise the missing
config.ru cases.
>From 222ae0a353eda446a480e5c4b473a218304f9594 Mon Sep 17 00:00:00 2001
From: Hongli Lai (Phusion) <hongli@phusion.nl>
Date: Tue, 8 Jun 2010 13:22:25 +0200
Subject: [PATCH] Fix unicorn_rails compatibility with the latest Rails 3 code
This allows us to properly detect Rails 3 installations
in cases where config.ru is not present.
[ew: expanded commit message
fixed static file serving,
more flexible regexp for matching module ]
ref: mid.gmane.org/AANLkTiksBxIo_PFWoiPTWi1entXZRb7D2uE-Rl7H3lbw@mail.gmail.com
Acked-by: Eric Wong <normalperson@yhbt.net>
---
bin/unicorn_rails | 26 ++++++++++++++++++++++++--
1 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/bin/unicorn_rails b/bin/unicorn_rails
index 45a9b11..ed235ba 100755
--- a/bin/unicorn_rails
+++ b/bin/unicorn_rails
@@ -109,6 +109,24 @@ end
ru = ARGV[0] || (File.exist?('config.ru') ? 'config.ru' : nil)
+def rails_dispatcher
+ if ::Rails::VERSION::MAJOR >= 3 && ::File.exist?('config/application.rb')
+ if ::File.read('config/application.rb') =~ /^module\s+([\w:]+)\s*$/
+ app_module = Object.const_get($1)
+ begin
+ result = app_module::Application
+ rescue NameError
+ end
+ end
+ end
+
+ if result.nil? && defined?(ActionController::Dispatcher)
+ result = ActionController::Dispatcher.new
+ end
+
+ result || abort("Unable to locate the application dispatcher class")
+end
+
def rails_builder(daemonize)
# this lambda won't run until after forking if preload_app is false
lambda do ||
@@ -149,8 +167,12 @@ def rails_builder(daemonize)
use Rails::Rack::LogTailer unless daemonize
use Rails::Rack::Debugger if $DEBUG
map(map_path) do
- use Rails::Rack::Static
- run ActionController::Dispatcher.new
+ if defined?(ActionDispatch::Static)
+ use ActionDispatch::Static, "#{Rails.root}/public"
+ else
+ use Rails::Rack::Static
+ end
+ run rails_dispatcher
end
end
end.to_app
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 7%]
* [ANN] unicorn 0.990.0 - inching towards 1.0
@ 2010-06-08 9:51 2% Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-06-08 9:51 UTC (permalink / raw)
To: mongrel-unicorn
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/
* mongrel-unicorn@rubyforge.org
* git://git.bogomips.org/unicorn.git
Changes:
Thanks to Augusto Becciu for finding a bug in the HTTP parser
that caused a TypeError (and 500) when a rare client set the
"Version:" header which conflicts with the HTTP_VERSION header
we parse in the first line of the request[1].
Horizontal tabs are now allowed as leading whitespace in header
values as according to RFC 2616 as pointed out by
Iñaki Baz Castillo[2].
Taking a hint from Rack 1.1, the "logger" configuration
parameter no longer requires a "close" method. This means some
more Logger replacements may be used.
There's a new, optional, Unicorn (and maybe Passenger)-only
middleware, Unicorn::OobGC[2] that runs GC outside of the normal
request/response cycle to help out memory-hungry applications.
Thanks to Luke Melia for being brave enough to test and report
back on my big_app_gc.rb monkey patch[3] which lead up to this.
Rails 3 (beta) support:
Using "unicorn" is still recommended as Rails 3 comes with
a config.ru, but "unicorn_rails" is cleaned up a bit and
*should* work as well as "unicorn" out-of-the-box. Feedback
is much appreciated.
Rubinius updates:
USR2 binary upgrades are broken due to
{TCPServer,UNIXServer}.for_fd[5][6] being broken
(differently).
Repeatedly hitting the server with signals in a tight
loop is unusual and not recommended[7].
There are some workarounds and general code cleanups for other
issues[8], as well but things should generally work unless you
need USR2 upgrades. Feedback and reports would be greatly
appreciated as usual.
MRI support:
All tests (except old Rails) run and pass under 1.9.2-preview3.
1.8.7 and 1.9.1 work well as usual and will continue to be
supported indefinitely.
Lets hope this is the last release before 1.0. Please report
any issues on the mailing list[9] or email us privately[a].
Don't send HTML mail.
[1] - http://mid.gmane.org/AANLkTimuGgcwNAMcVZdViFWdF-UcW_RGyZAue7phUXps@mail.gmail.com
[2] - http://mid.gmane.org/i2xcc1f582e1005070651u294bd83oc73d1e0adf72373a@mail.gmail.com
[3] - http://unicorn.bogomips.org/Unicorn/OobGC.html
[4] - http://unicorn.bogomips.org/examples/big_app_gc.rb
[5] - http://github.com/evanphx/rubinius/issues/354
[6] - http://github.com/evanphx/rubinius/issues/355
[7] - http://github.com/evanphx/rubinius/issues/356
[8] - http://github.com/evanphx/rubinius/issues/347
[9] - mailto:mongrel-unicorn@rubyforge.org
[a] - mailto:unicorn@bogomips.org
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: Read error: #<TypeError: can't modify frozen string> raised from HttpParser
2010-06-08 2:45 9% ` Eric Wong
@ 2010-06-08 3:01 0% ` Augusto Becciu
0 siblings, 0 replies; 200+ results
From: Augusto Becciu @ 2010-06-08 3:01 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
That looks perfect. Thanks Eric!
On Mon, Jun 7, 2010 at 11:45 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Augusto Becciu <augusto@jadedpixel.com> wrote:
>> Hi Eric,
>>
>> Thanks for the ideas.
>>
>> Ended up adding some debugging code to unicorn that lead me to the
>> culprit of the problem. It turned out being a bug in the HttpParser.
>
> Thank you Augusto,
>
> Your explanation was good so I'll just use it as a commit message
> and credit you as the author. See the patch below and let me know
> if everything looks alright before I push it out.
>
> I have a few small things to go over, but I'll be releasing 0.999.0
> tonight (which I hope will be the last before we finally celebrate
> have a 1.0.0 release).
>
> From 7d2295fa774d1c98dfbde2b09d93d58712253d24 Mon Sep 17 00:00:00 2001
> From: Augusto Becciu <augusto@jadedpixel.com>
> Date: Mon, 7 Jun 2010 23:02:43 -0300
> Subject: [PATCH] http: ignore Version: header if explicitly set by client
>
> When Unicorn receives a request with a "Version" header, the
> HttpParser transforms it into "HTTP_VERSION". After that tries to add
> it to the request hash which already contains a "HTTP_VERSION" key
> with the actual http version of the request. So it tries to append the
> new value separated by a comma. But since the http version is a
> freezed constant, the TypeError exception is raised.
>
> According to the HTTP RFC
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.1) a
> "Version" header is valid. However, it's not supported in rack, since
> rack has a HTTP_VERSION env variable for the http version. So I think
> the easiest way to deal with this problem is to just ignore the header
> since it is extremely unusual. We were getting it from a crappy bot.
>
> ref: http://mid.gmane.org/AANLkTimuGgcwNAMcVZdViFWdF-UcW_RGyZAue7phUXps@mail.gmail.com
>
> Acked-by: Eric Wong <normalperson@yhbt.net>
> ---
> ext/unicorn_http/unicorn_http.rl | 9 +++++++++
> test/unit/test_http_parser_ng.rb | 20 ++++++++++++++++++++
> 2 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/ext/unicorn_http/unicorn_http.rl b/ext/unicorn_http/unicorn_http.rl
> index 264db68..aa23024 100644
> --- a/ext/unicorn_http/unicorn_http.rl
> +++ b/ext/unicorn_http/unicorn_http.rl
> @@ -197,6 +197,15 @@ static void write_value(VALUE req, struct http_parser *hp,
> assert_frozen(f);
> }
>
> + /*
> + * ignore "Version" headers since they conflict with the HTTP_VERSION
> + * rack env variable.
> + */
> + if (rb_str_cmp(f, g_http_version) == 0) {
> + hp->cont = Qnil;
> + return;
> + }
> +
> e = rb_hash_aref(req, f);
> if (NIL_P(e)) {
> hp->cont = rb_hash_aset(req, f, v);
> diff --git a/test/unit/test_http_parser_ng.rb b/test/unit/test_http_parser_ng.rb
> index a067ac8..cb30f32 100644
> --- a/test/unit/test_http_parser_ng.rb
> +++ b/test/unit/test_http_parser_ng.rb
> @@ -440,4 +440,24 @@ class HttpParserNgTest < Test::Unit::TestCase
> end
> end
>
> + def test_ignore_version_header
> + http = "GET / HTTP/1.1\r\nVersion: hello\r\n\r\n"
> + req = {}
> + assert_equal req, @parser.headers(req, http)
> + assert_equal '', http
> + expect = {
> + "SERVER_NAME" => "localhost",
> + "rack.url_scheme" => "http",
> + "REQUEST_PATH" => "/",
> + "SERVER_PROTOCOL" => "HTTP/1.1",
> + "PATH_INFO" => "/",
> + "HTTP_VERSION" => "HTTP/1.1",
> + "REQUEST_URI" => "/",
> + "SERVER_PORT" => "80",
> + "REQUEST_METHOD" => "GET",
> + "QUERY_STRING" => ""
> + }
> + assert_equal expect, req
> + end
> +
> end
> --
> Eric Wong
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Read error: #<TypeError: can't modify frozen string> raised from HttpParser
2010-06-08 2:02 5% ` Augusto Becciu
@ 2010-06-08 2:45 9% ` Eric Wong
2010-06-08 3:01 0% ` Augusto Becciu
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2010-06-08 2:45 UTC (permalink / raw)
To: Augusto Becciu; +Cc: unicorn list
Augusto Becciu <augusto@jadedpixel.com> wrote:
> Hi Eric,
>
> Thanks for the ideas.
>
> Ended up adding some debugging code to unicorn that lead me to the
> culprit of the problem. It turned out being a bug in the HttpParser.
Thank you Augusto,
Your explanation was good so I'll just use it as a commit message
and credit you as the author. See the patch below and let me know
if everything looks alright before I push it out.
I have a few small things to go over, but I'll be releasing 0.999.0
tonight (which I hope will be the last before we finally celebrate
have a 1.0.0 release).
>From 7d2295fa774d1c98dfbde2b09d93d58712253d24 Mon Sep 17 00:00:00 2001
From: Augusto Becciu <augusto@jadedpixel.com>
Date: Mon, 7 Jun 2010 23:02:43 -0300
Subject: [PATCH] http: ignore Version: header if explicitly set by client
When Unicorn receives a request with a "Version" header, the
HttpParser transforms it into "HTTP_VERSION". After that tries to add
it to the request hash which already contains a "HTTP_VERSION" key
with the actual http version of the request. So it tries to append the
new value separated by a comma. But since the http version is a
freezed constant, the TypeError exception is raised.
According to the HTTP RFC
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.1) a
"Version" header is valid. However, it's not supported in rack, since
rack has a HTTP_VERSION env variable for the http version. So I think
the easiest way to deal with this problem is to just ignore the header
since it is extremely unusual. We were getting it from a crappy bot.
ref: http://mid.gmane.org/AANLkTimuGgcwNAMcVZdViFWdF-UcW_RGyZAue7phUXps@mail.gmail.com
Acked-by: Eric Wong <normalperson@yhbt.net>
---
ext/unicorn_http/unicorn_http.rl | 9 +++++++++
test/unit/test_http_parser_ng.rb | 20 ++++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/ext/unicorn_http/unicorn_http.rl b/ext/unicorn_http/unicorn_http.rl
index 264db68..aa23024 100644
--- a/ext/unicorn_http/unicorn_http.rl
+++ b/ext/unicorn_http/unicorn_http.rl
@@ -197,6 +197,15 @@ static void write_value(VALUE req, struct http_parser *hp,
assert_frozen(f);
}
+ /*
+ * ignore "Version" headers since they conflict with the HTTP_VERSION
+ * rack env variable.
+ */
+ if (rb_str_cmp(f, g_http_version) == 0) {
+ hp->cont = Qnil;
+ return;
+ }
+
e = rb_hash_aref(req, f);
if (NIL_P(e)) {
hp->cont = rb_hash_aset(req, f, v);
diff --git a/test/unit/test_http_parser_ng.rb b/test/unit/test_http_parser_ng.rb
index a067ac8..cb30f32 100644
--- a/test/unit/test_http_parser_ng.rb
+++ b/test/unit/test_http_parser_ng.rb
@@ -440,4 +440,24 @@ class HttpParserNgTest < Test::Unit::TestCase
end
end
+ def test_ignore_version_header
+ http = "GET / HTTP/1.1\r\nVersion: hello\r\n\r\n"
+ req = {}
+ assert_equal req, @parser.headers(req, http)
+ assert_equal '', http
+ expect = {
+ "SERVER_NAME" => "localhost",
+ "rack.url_scheme" => "http",
+ "REQUEST_PATH" => "/",
+ "SERVER_PROTOCOL" => "HTTP/1.1",
+ "PATH_INFO" => "/",
+ "HTTP_VERSION" => "HTTP/1.1",
+ "REQUEST_URI" => "/",
+ "SERVER_PORT" => "80",
+ "REQUEST_METHOD" => "GET",
+ "QUERY_STRING" => ""
+ }
+ assert_equal expect, req
+ end
+
end
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 9%]
* Re: Read error: #<TypeError: can't modify frozen string> raised from HttpParser
2010-06-03 23:40 0% ` Eric Wong
@ 2010-06-08 2:02 5% ` Augusto Becciu
2010-06-08 2:45 9% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Augusto Becciu @ 2010-06-08 2:02 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
On Thu, Jun 3, 2010 at 8:40 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Augusto Becciu <augusto@jadedpixel.com> wrote:
>> On Wed, Jun 2, 2010 at 6:38 PM, Eric Wong <normalperson@yhbt.net> wrote:
>> > Augusto Becciu <augusto@jadedpixel.com> wrote:
>> >> On Wed, Jun 2, 2010 at 5:25 PM, Eric Wong <normalperson@yhbt.net> wrote:
>> >> > Augusto Becciu <augusto@jadedpixel.com> wrote:
>> >> >> Hey guys,
>> >> >>
>> >> >> Started running unicorn in a production server like two weeks ago.
>> >> >> It's been running smoothly, but looking at the logs found 44
>> >> >> exceptions like this:
>> >> >>
>> >> >> E, [2010-06-02T16:17:15.117071 #22680] ERROR -- : Read error:
>> >> >> #<TypeError: can't modify frozen string>
>> >> >> E, [2010-06-02T16:17:15.117270 #22680] ERROR -- :
>> >> >> /usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn/http_request.rb:59:in
>> >> >> `headers'
>> >> >
>> >> > <snip>
>> >> >
>> >> >> Ruby version: ruby 1.8.7 (2009-12-24 patchlevel 248) [i686-linux],
>> >> >> MBARI 0x8770, Ruby Enterprise Edition 2010.01
>
> <snip>
>
>> >> There's no way our application could be freezing that constant, at
>> >> least not intentionally.
>
> <snip>
>
>> Thanks Eric! Unfortunately after completely disabling RPM, we keep
>> getting that error. :(
>>
>> What else could it be?
>
> Any details about your application you're allowed to share can help us,
> especially a list of library/gem dependencies and versions.
>
> I would grep through your gems and vendor directories to ensure there's
> nothing freezing objects it shouldn't freeze. It could also be a buggy
> C extension corrupting memory somewhere, too...
>
> This isn't happening for all your worker processes, is it?
>
> If your application logs show which PID handled each request, you can
> join the PIDs from the application logs with PIDs in the error logs
> generated by Unicorn. That lets you narrow down the possible requests
> that could trigger the errors and help you reproduce the problem sooner.
>
> This is one of my favorite features of one-request-per-process model
> is that you can easily narrow down which request is triggering a
> particular bug without worrying about race conditions from other
> requests.
>
> This is certainly the first time I've heard of this problem, so I think
> it's specific to something in your application/environment.
>
> --
> Eric Wong
>
Hi Eric,
Thanks for the ideas.
Ended up adding some debugging code to unicorn that lead me to the
culprit of the problem. It turned out being a bug in the HttpParser.
When Unicorn receives a request with a "Version" header, the
HttpParser transforms it into "HTTP_VERSION". After that tries to add
it to the request hash which already contains a "HTTP_VERSION" key
with the actual http version of the request. So it tries to append the
new value separated by a comma. But since the http version is a
freezed constant, the TypeError exception is raised.
According to the HTTP RFC
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.1) a
"Version" header is valid. However, it's not supported in rack, since
rack has a HTTP_VERSION env variable for the http version. So I think
the easiest way to deal with this problem is to just ignore the header
since it is extremely unusual. We were getting it from a crappy bot.
Below is a proposed patch.
Thanks a lot for your help!
Augusto
diff --git a/ext/unicorn_http/unicorn_http.rl b/ext/unicorn_http/unicorn_http.rl
index 264db68..aa23024 100644
--- a/ext/unicorn_http/unicorn_http.rl
+++ b/ext/unicorn_http/unicorn_http.rl
@@ -197,6 +197,15 @@ static void write_value(VALUE req, struct http_parser *hp,
assert_frozen(f);
}
+ /*
+ * ignore "Version" headers since they conflict with the HTTP_VERSION
+ * rack env variable.
+ */
+ if (rb_str_cmp(f, g_http_version) == 0) {
+ hp->cont = Qnil;
+ return;
+ }
+
e = rb_hash_aref(req, f);
if (NIL_P(e)) {
hp->cont = rb_hash_aset(req, f, v);
diff --git a/test/unit/test_http_parser_ng.rb b/test/unit/test_http_parser_ng.rb
index a067ac8..cb30f32 100644
--- a/test/unit/test_http_parser_ng.rb
+++ b/test/unit/test_http_parser_ng.rb
@@ -440,4 +440,24 @@ class HttpParserNgTest < Test::Unit::TestCase
end
end
+ def test_ignore_version_header
+ http = "GET / HTTP/1.1\r\nVersion: hello\r\n\r\n"
+ req = {}
+ assert_equal req, @parser.headers(req, http)
+ assert_equal '', http
+ expect = {
+ "SERVER_NAME" => "localhost",
+ "rack.url_scheme" => "http",
+ "REQUEST_PATH" => "/",
+ "SERVER_PROTOCOL" => "HTTP/1.1",
+ "PATH_INFO" => "/",
+ "HTTP_VERSION" => "HTTP/1.1",
+ "REQUEST_URI" => "/",
+ "SERVER_PORT" => "80",
+ "REQUEST_METHOD" => "GET",
+ "QUERY_STRING" => ""
+ }
+ assert_equal expect, req
+ end
+
end
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 5%]
* unicorn_rails cleanup (possible fix for Rails3) pushed
@ 2010-06-04 1:58 20% Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-06-04 1:58 UTC (permalink / raw)
To: mongrel-unicorn
Hi all,
I've pushed the following patch out go git://git.bogomips.org/unicorn
along with a few other Rails-related test updates. This is more of a
shotgun fix (but less code is better :) since I haven't been able to
reproduce the brokeness people have been seeing with "unicorn_rails"
and Rails 3 betas.
Even though "unicorn" works perfectly well for Rails3, some folks will
inevitably run "unicorn_rails" because of the "rails" in its name.
If I were to do it all over again, I would've just made everybody write
config.ru files for Rails. But yes, programming is like sex, make one
mistake and support it for life :)
You can grab a git gem here, too:
http://unicorn.bogomips.org/files/unicorn-0.99.0.16.g59a625.gem
>From 4b44e21957e4cb8ec6ace5604fbe096dfd8959d2 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Thu, 3 Jun 2010 22:52:11 +0000
Subject: [PATCH] unicorn_rails: avoid duplicating config.ru logic
This should allow "unicorn_rails" to be used seamlessly
with Rails 3 projects which package config.ru for you.
---
bin/unicorn_rails | 50 ++++++++++++++------------------------------------
1 files changed, 14 insertions(+), 36 deletions(-)
diff --git a/bin/unicorn_rails b/bin/unicorn_rails
index 72ab288..45a9b11 100755
--- a/bin/unicorn_rails
+++ b/bin/unicorn_rails
@@ -109,53 +109,30 @@ end
ru = ARGV[0] || (File.exist?('config.ru') ? 'config.ru' : nil)
-if ru && ru =~ /\.ru\z/
- # parse embedded command-line options in config.ru comments
- /^#\\(.*)/ =~ File.read(ru) and opts.parse!($1.split(/\s+/))
-end
-
-def rails_builder(ru, daemonize)
+def rails_builder(daemonize)
# this lambda won't run until after forking if preload_app is false
lambda do ||
# Load Rails and (possibly) the private version of Rack it bundles.
begin
require 'config/boot'
+ require 'config/environment'
rescue LoadError => err
abort "#$0 must be run inside RAILS_ROOT: #{err.inspect}"
end
- inner_app = case ru
- when nil
- require 'config/environment'
-
- defined?(::Rails::VERSION::STRING) or
- abort "Rails::VERSION::STRING not defined by config/{boot,environment}"
- # it seems Rails >=2.2 support Rack, but only >=2.3 requires it
- old_rails = case ::Rails::VERSION::MAJOR
- when 0, 1 then true
- when 2 then Rails::VERSION::MINOR < 3 ? true : false
- else
- false
- end
-
- if old_rails
- require 'unicorn/app/old_rails'
- Unicorn::App::OldRails.new
- else
- ActionController::Dispatcher.new
- end
- when /\.ru$/
- raw = File.read(ru)
- raw.sub!(/^__END__\n.*/, '')
- eval("Rack::Builder.new {(#{raw}\n)}.to_app", TOPLEVEL_BINDING, ru)
+ defined?(::Rails::VERSION::STRING) or
+ abort "Rails::VERSION::STRING not defined by config/{boot,environment}"
+ # it seems Rails >=2.2 support Rack, but only >=2.3 requires it
+ old_rails = case ::Rails::VERSION::MAJOR
+ when 0, 1 then true
+ when 2 then Rails::VERSION::MINOR < 3 ? true : false
else
- require ru
- Object.const_get(File.basename(ru, '.rb').capitalize)
+ false
end
Rack::Builder.new do
map_path = ENV['RAILS_RELATIVE_URL_ROOT'] || '/'
- if inner_app.class.to_s == "Unicorn::App::OldRails"
+ if old_rails
if map_path != '/'
# patches + tests welcome, but I really cbf to deal with this
# since all apps I've ever dealt with just use "/" ...
@@ -163,23 +140,24 @@ def rails_builder(ru, daemonize)
end
$stderr.puts "LogTailer not available for Rails < 2.3" unless daemonize
$stderr.puts "Debugger not available" if $DEBUG
+ require 'unicorn/app/old_rails'
map(map_path) do
use Unicorn::App::OldRails::Static
- run inner_app
+ run Unicorn::App::OldRails.new
end
else
use Rails::Rack::LogTailer unless daemonize
use Rails::Rack::Debugger if $DEBUG
map(map_path) do
use Rails::Rack::Static
- run inner_app
+ run ActionController::Dispatcher.new
end
end
end.to_app
end
end
-app = rails_builder(ru, daemonize)
+app = ru ? Unicorn.builder(ru, opts) : rails_builder(daemonize)
options[:listeners] << "#{host}:#{port}" if set_listener
if $DEBUG
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 20%]
* Re: Read error: #<TypeError: can't modify frozen string> raised from HttpParser
2010-06-03 23:05 0% ` Augusto Becciu
@ 2010-06-03 23:40 0% ` Eric Wong
2010-06-08 2:02 5% ` Augusto Becciu
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2010-06-03 23:40 UTC (permalink / raw)
To: Augusto Becciu; +Cc: unicorn list
Augusto Becciu <augusto@jadedpixel.com> wrote:
> On Wed, Jun 2, 2010 at 6:38 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > Augusto Becciu <augusto@jadedpixel.com> wrote:
> >> On Wed, Jun 2, 2010 at 5:25 PM, Eric Wong <normalperson@yhbt.net> wrote:
> >> > Augusto Becciu <augusto@jadedpixel.com> wrote:
> >> >> Hey guys,
> >> >>
> >> >> Started running unicorn in a production server like two weeks ago.
> >> >> It's been running smoothly, but looking at the logs found 44
> >> >> exceptions like this:
> >> >>
> >> >> E, [2010-06-02T16:17:15.117071 #22680] ERROR -- : Read error:
> >> >> #<TypeError: can't modify frozen string>
> >> >> E, [2010-06-02T16:17:15.117270 #22680] ERROR -- :
> >> >> /usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn/http_request.rb:59:in
> >> >> `headers'
> >> >
> >> > <snip>
> >> >
> >> >> Ruby version: ruby 1.8.7 (2009-12-24 patchlevel 248) [i686-linux],
> >> >> MBARI 0x8770, Ruby Enterprise Edition 2010.01
<snip>
> >> There's no way our application could be freezing that constant, at
> >> least not intentionally.
<snip>
> Thanks Eric! Unfortunately after completely disabling RPM, we keep
> getting that error. :(
>
> What else could it be?
Any details about your application you're allowed to share can help us,
especially a list of library/gem dependencies and versions.
I would grep through your gems and vendor directories to ensure there's
nothing freezing objects it shouldn't freeze. It could also be a buggy
C extension corrupting memory somewhere, too...
This isn't happening for all your worker processes, is it?
If your application logs show which PID handled each request, you can
join the PIDs from the application logs with PIDs in the error logs
generated by Unicorn. That lets you narrow down the possible requests
that could trigger the errors and help you reproduce the problem sooner.
This is one of my favorite features of one-request-per-process model
is that you can easily narrow down which request is triggering a
particular bug without worrying about race conditions from other
requests.
This is certainly the first time I've heard of this problem, so I think
it's specific to something in your application/environment.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Read error: #<TypeError: can't modify frozen string> raised from HttpParser
2010-06-02 21:38 0% ` Eric Wong
@ 2010-06-03 23:05 0% ` Augusto Becciu
2010-06-03 23:40 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Augusto Becciu @ 2010-06-03 23:05 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
On Wed, Jun 2, 2010 at 6:38 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Augusto Becciu <augusto@jadedpixel.com> wrote:
>> On Wed, Jun 2, 2010 at 5:25 PM, Eric Wong <normalperson@yhbt.net> wrote:
>> > Augusto Becciu <augusto@jadedpixel.com> wrote:
>> >> Hey guys,
>> >>
>> >> Started running unicorn in a production server like two weeks ago.
>> >> It's been running smoothly, but looking at the logs found 44
>> >> exceptions like this:
>> >>
>> >> E, [2010-06-02T16:17:15.117071 #22680] ERROR -- : Read error:
>> >> #<TypeError: can't modify frozen string>
>> >> E, [2010-06-02T16:17:15.117270 #22680] ERROR -- :
>> >> /usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn/http_request.rb:59:in
>> >> `headers'
>> >
>> > <snip>
>> >
>> >> Ruby version: ruby 1.8.7 (2009-12-24 patchlevel 248) [i686-linux],
>> >> MBARI 0x8770, Ruby Enterprise Edition 2010.01
>> >>
>> >> Any ideas? Maybe a bug in the http parser?
>> >
>> > Hi Augusto,
>> >
>> > Somehow the reusable Unicorn::HttpRequest::BUF string constant is
>> > getting frozen when it shouldn't be. Do you have any code that could
>> > be freezing that string? That string object should never be returned to
>> > the application via any code paths in Unicorn (env or tee_input).
>
> Please don't top post, thanks.
>
>> Hi Eric,
>>
>> There's no way our application could be freezing that constant, at
>> least not intentionally.
>>
>> We're using New Replic's RPM plugin, but checked it out and couldn't
>> find anything that could do that.
>>
>> http://github.com/newrelic/rpm/blob/master/lib/new_relic/agent/instrumentation/unicorn_instrumentation.rb
>>
>> Let me know if I can help in any way.
>
> Are you able to reproduce the problem without the RPM plugin? I've
> never used RPM myself, but we've heard of (and proposed some fixes)
> with it over the recent months.
>
> Some of those problems could be segfaults (on x86_64), but memory
> corruption could also cause an unintentional freeze, as well...
>
> In particular, could you try disabling compression when sending things
> upstream?
>
> (totally untested, I don't even have a New Relic account[1]).
>
> diff --git a/lib/new_relic/agent/agent.rb b/lib/new_relic/agent/agent.rb
> index 928c6d7..5e60520 100644
> --- a/lib/new_relic/agent/agent.rb
> +++ b/lib/new_relic/agent/agent.rb
> @@ -554,7 +554,7 @@ module NewRelic
> dump_size = dump.size
>
> # small payloads don't need compression
> - return [dump, 'identity'] if dump_size < 2000
> + return [dump, 'identity']
>
> # medium payloads get fast compression, to save CPU
> # big payloads get all the compression possible, to stay under
> ---
>
> There's also 1787b22eb2d8ab8b4046ae14be349aa487abc7b5 in the
> v2.12.2_beta tag of git://github.com/newrelic/rpm which raises
> the compression threshold, too...
>
> --
> Eric Wong
>
> [1] - yes I'm allergic to signing up for commercial things
>
Thanks Eric! Unfortunately after completely disabling RPM, we keep
getting that error. :(
What else could it be?
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Fwd: Support for Soft Timeout in Unicorn
2010-06-03 18:32 3% ` Pierre Baillet
@ 2010-06-03 18:47 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-06-03 18:47 UTC (permalink / raw)
To: Pierre Baillet; +Cc: mongrel-unicorn
Pierre Baillet <oct@fotonauts.com> wrote:
> Eric,
>
> On Thu, Jun 3, 2010 at 8:22 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > 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
> > had time.
>
> I also think that doing this as a Rack middleware is probably the
> right way to do that kind of worker management. However the
> application we use at fotopedia is still Rails 2.1 based (hence not
> Rack compatible AFAIK). This probably means we'll have keep on
> maintaining this slightly hacked version on our own then.
Actually, internally, Unicorn only knows about Rack and wraps older
CGI-based Rails using the Unicorn::App::OldRails application (via
Unicorn::CGIWrapper).
"unicorn_rails" basically wraps up the following config for you,
but you could achieve the same effect using "unicorn" and an
explicitly written config.ru:
------------ config.ru -------------
ENV["RAILS_ENV"] ||= ENV["RACK_ENV"]
require 'config/boot'
require 'config/environment'
require 'unicorn/app/old_rails'
require 'unwritten_timeout_middleware'
use UnwrittenTimeoutMiddleware # :)
use Unicorn::App::OldRails::Static # optional
run Unicorn::App::OldRails.new
------------------------------------
> Thank you for Unicorn ! :)
No problem :)
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Fwd: Support for Soft Timeout in Unicorn
@ 2010-06-03 18:32 3% ` Pierre Baillet
2010-06-03 18:47 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Pierre Baillet @ 2010-06-03 18:32 UTC (permalink / raw)
To: Eric Wong; +Cc: mongrel-unicorn
Eric,
On Thu, Jun 3, 2010 at 8:22 PM, Eric Wong <normalperson@yhbt.net> wrote:
> 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
> had time.
I also think that doing this as a Rack middleware is probably the
right way to do that kind of worker management. However the
application we use at fotopedia is still Rails 2.1 based (hence not
Rack compatible AFAIK). This probably means we'll have keep on
maintaining this slightly hacked version on our own then.
Thank you for Unicorn ! :)
--
Pierre Baillet <oct@fotonauts.com>
http://www.fotopedia.com/
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Read error: #<TypeError: can't modify frozen string> raised from HttpParser
2010-06-02 20:47 0% ` Augusto Becciu
@ 2010-06-02 21:38 0% ` Eric Wong
2010-06-03 23:05 0% ` Augusto Becciu
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2010-06-02 21:38 UTC (permalink / raw)
To: Augusto Becciu; +Cc: unicorn list
Augusto Becciu <augusto@jadedpixel.com> wrote:
> On Wed, Jun 2, 2010 at 5:25 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > Augusto Becciu <augusto@jadedpixel.com> wrote:
> >> Hey guys,
> >>
> >> Started running unicorn in a production server like two weeks ago.
> >> It's been running smoothly, but looking at the logs found 44
> >> exceptions like this:
> >>
> >> E, [2010-06-02T16:17:15.117071 #22680] ERROR -- : Read error:
> >> #<TypeError: can't modify frozen string>
> >> E, [2010-06-02T16:17:15.117270 #22680] ERROR -- :
> >> /usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn/http_request.rb:59:in
> >> `headers'
> >
> > <snip>
> >
> >> Ruby version: ruby 1.8.7 (2009-12-24 patchlevel 248) [i686-linux],
> >> MBARI 0x8770, Ruby Enterprise Edition 2010.01
> >>
> >> Any ideas? Maybe a bug in the http parser?
> >
> > Hi Augusto,
> >
> > Somehow the reusable Unicorn::HttpRequest::BUF string constant is
> > getting frozen when it shouldn't be. Do you have any code that could
> > be freezing that string? That string object should never be returned to
> > the application via any code paths in Unicorn (env or tee_input).
Please don't top post, thanks.
> Hi Eric,
>
> There's no way our application could be freezing that constant, at
> least not intentionally.
>
> We're using New Replic's RPM plugin, but checked it out and couldn't
> find anything that could do that.
>
> http://github.com/newrelic/rpm/blob/master/lib/new_relic/agent/instrumentation/unicorn_instrumentation.rb
>
> Let me know if I can help in any way.
Are you able to reproduce the problem without the RPM plugin? I've
never used RPM myself, but we've heard of (and proposed some fixes)
with it over the recent months.
Some of those problems could be segfaults (on x86_64), but memory
corruption could also cause an unintentional freeze, as well...
In particular, could you try disabling compression when sending things
upstream?
(totally untested, I don't even have a New Relic account[1]).
diff --git a/lib/new_relic/agent/agent.rb b/lib/new_relic/agent/agent.rb
index 928c6d7..5e60520 100644
--- a/lib/new_relic/agent/agent.rb
+++ b/lib/new_relic/agent/agent.rb
@@ -554,7 +554,7 @@ module NewRelic
dump_size = dump.size
# small payloads don't need compression
- return [dump, 'identity'] if dump_size < 2000
+ return [dump, 'identity']
# medium payloads get fast compression, to save CPU
# big payloads get all the compression possible, to stay under
---
There's also 1787b22eb2d8ab8b4046ae14be349aa487abc7b5 in the
v2.12.2_beta tag of git://github.com/newrelic/rpm which raises
the compression threshold, too...
--
Eric Wong
[1] - yes I'm allergic to signing up for commercial things
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 0%]
* Re: Read error: #<TypeError: can't modify frozen string> raised from HttpParser
2010-06-02 20:25 0% ` Eric Wong
@ 2010-06-02 20:47 0% ` Augusto Becciu
2010-06-02 21:38 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Augusto Becciu @ 2010-06-02 20:47 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
Hi Eric,
There's no way our application could be freezing that constant, at
least not intentionally.
We're using New Replic's RPM plugin, but checked it out and couldn't
find anything that could do that.
http://github.com/newrelic/rpm/blob/master/lib/new_relic/agent/instrumentation/unicorn_instrumentation.rb
Let me know if I can help in any way.
Thanks,
Augusto
On Wed, Jun 2, 2010 at 5:25 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Augusto Becciu <augusto@jadedpixel.com> wrote:
>> Hey guys,
>>
>> Started running unicorn in a production server like two weeks ago.
>> It's been running smoothly, but looking at the logs found 44
>> exceptions like this:
>>
>> E, [2010-06-02T16:17:15.117071 #22680] ERROR -- : Read error:
>> #<TypeError: can't modify frozen string>
>> E, [2010-06-02T16:17:15.117270 #22680] ERROR -- :
>> /usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn/http_request.rb:59:in
>> `headers'
>
> <snip>
>
>> Ruby version: ruby 1.8.7 (2009-12-24 patchlevel 248) [i686-linux],
>> MBARI 0x8770, Ruby Enterprise Edition 2010.01
>>
>> Any ideas? Maybe a bug in the http parser?
>
> Hi Augusto,
>
> Somehow the reusable Unicorn::HttpRequest::BUF string constant is
> getting frozen when it shouldn't be. Do you have any code that could
> be freezing that string? That string object should never be returned to
> the application via any code paths in Unicorn (env or tee_input).
>
> --
> Eric Wong
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Read error: #<TypeError: can't modify frozen string> raised from HttpParser
2010-06-02 18:01 2% Read error: #<TypeError: can't modify frozen string> raised from HttpParser Augusto Becciu
@ 2010-06-02 20:25 0% ` Eric Wong
2010-06-02 20:47 0% ` Augusto Becciu
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2010-06-02 20:25 UTC (permalink / raw)
To: unicorn list; +Cc: Augusto Becciu
Augusto Becciu <augusto@jadedpixel.com> wrote:
> Hey guys,
>
> Started running unicorn in a production server like two weeks ago.
> It's been running smoothly, but looking at the logs found 44
> exceptions like this:
>
> E, [2010-06-02T16:17:15.117071 #22680] ERROR -- : Read error:
> #<TypeError: can't modify frozen string>
> E, [2010-06-02T16:17:15.117270 #22680] ERROR -- :
> /usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn/http_request.rb:59:in
> `headers'
<snip>
> Ruby version: ruby 1.8.7 (2009-12-24 patchlevel 248) [i686-linux],
> MBARI 0x8770, Ruby Enterprise Edition 2010.01
>
> Any ideas? Maybe a bug in the http parser?
Hi Augusto,
Somehow the reusable Unicorn::HttpRequest::BUF string constant is
getting frozen when it shouldn't be. Do you have any code that could
be freezing that string? That string object should never be returned to
the application via any code paths in Unicorn (env or tee_input).
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Read error: #<TypeError: can't modify frozen string> raised from HttpParser
@ 2010-06-02 18:01 2% Augusto Becciu
2010-06-02 20:25 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Augusto Becciu @ 2010-06-02 18:01 UTC (permalink / raw)
To: mongrel-unicorn
Hey guys,
Started running unicorn in a production server like two weeks ago.
It's been running smoothly, but looking at the logs found 44
exceptions like this:
E, [2010-06-02T16:17:15.117071 #22680] ERROR -- : Read error:
#<TypeError: can't modify frozen string>
E, [2010-06-02T16:17:15.117270 #22680] ERROR -- :
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn/http_request.rb:59:in
`headers'
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn/http_request.rb:59:in
`read'
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn.rb:643:in
`process_client'
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn.rb:716:in `worker_loop'
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn.rb:714:in `each'
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn.rb:714:in `worker_loop'
/u/apps/xxxx/releases/20100602004926/vendor/plugins/newrelic_rpm/lib/new_relic/agent/instrumentation/unicorn_instrumentation.rb:7:in
`call'
/u/apps/xxxx/releases/20100602004926/vendor/plugins/newrelic_rpm/lib/new_relic/agent/instrumentation/unicorn_instrumentation.rb:7:in
`worker_loop'
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn.rb:605:in
`spawn_missing_workers'
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn.rb:602:in `fork'
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn.rb:602:in
`spawn_missing_workers'
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn.rb:598:in `each'
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn.rb:598:in
`spawn_missing_workers'
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn.rb:612:in
`maintain_worker_count'
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn.rb:276:in `start'
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/lib/unicorn.rb:28:in `run'
/usr/lib/ruby/gems/1.8/gems/unicorn-0.99.0/bin/unicorn_rails:203
/usr/bin/unicorn_rails:26:in `load'
/usr/bin/unicorn_rails:26
Ruby version: ruby 1.8.7 (2009-12-24 patchlevel 248) [i686-linux],
MBARI 0x8770, Ruby Enterprise Edition 2010.01
Any ideas? Maybe a bug in the http parser?
Thanks,
Augusto
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: Prematurely closed connection
@ 2010-05-13 20:13 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-05-13 20:13 UTC (permalink / raw)
To: unicorn list
Paul Carey <paul.p.carey@gmail.com> wrote:
> Hi
>
> I've come across a puzzling issue. The code segment below works as
> expected, but if I replace :error => true with :error =>
> invite.errors, nginx serves a 502 as per the log below. invite.errors
> is normal hash.
>
> I'm using a bundled merb 1.1 with Unicorn 0.99. Unicorn is a system
> gem. I'm running nginx 0.7.65. I've only experienced this issue with
> nginx / unicorn.
> I'd be grateful for any thoughts or pointers.
>
> Many thanks
> Paul
>
> == controller action, serving json
> if invite.save
> display :ok => true
> else
> Merb.logger.info "invite.errors #{invite.errors}"
> display :error => true
> end
<snip>
Hi Paul,
> == unicorn.stderr.log
> I, [2010-05-13T16:34:03.869423 #15332] INFO -- : reaped
> #<Process::Status: pid 15398 SIGSEGV (signal 11)> worker=15I,
^^^^^^^
Uh oh, something is causing the Unicorn process to segfault in the
response phase. Since Unicorn is only running Ruby code at that point,
I suspect there's something in your JSON enoder that's not liking
the serialization of invite.errors...
I'm not familiar with Merb at all, but I'd be curious to see how your
JSON encoder is handling the "invite.errors" hash.
Which version of Ruby, JSON/Yajl library, etc are you using?
Can you get us a backtrace?
Can you run with RACK_ENV=development to get Rack::Lint onto your
middleware stack? Perhaps Merb isn't returning a 100% valid Rack
response and Rack::Lint will notice.
Thanks for any info you can provide.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Some issues in the HTTP parser (and suggestions)
@ 2010-05-07 18:33 2% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-05-07 18:33 UTC (permalink / raw)
To: unicorn list
Iñaki Baz Castillo <ibc@aliax.net> wrote:
> Hi, by inspecting the Ragel grammar of the HTTP parser (coming from
> Mongrel) I've realized of some possible issues and bugs:
>
>
> hostname = (alnum | "-" | "." | "_")+;
>
> - It doesn't allow IPv6. This is important IMHO.
> - It allows "_" which is an invalid symbol (not valid for a domain).
>
> I suggest:
> hostname = (alnum | "-" | "." | "[" | "]" | ":")+;
Hi Iñaki,
Underscore isn't valid for hostnames, but it is allowed in domain names
and most DNS servers will resolve them. I've personally seen websites
with underscores in their domain names in the wild[1].
We'll have to test the IPv6 addresses and probably split that out into a
separate regexp since ":" would raise issues with the port number in
existing cases. This is probably something for post-1.0.
> ------------------
>
> host_with_port = (hostname (":" digit*)?) >mark %host;
>
> - It allows something ugly as "mydomain.org:"
>
> I suggest:
> host_with_port = (hostname (":" digit{1,5})?) >mark %host;
It's ugly, but section 3.2.2 of RFC 2396 appears to allows it.
> ------------------
>
> message_header = ((field_name ":" " "* field_value)|value_cont) :> CRLF;
>
> - It doesn't allow valid spaces before ":" as:
> Host : mydomain.org
Spaces before the ":" aren't allowed in rfc2616, and I have yet to see
evidence of clients sending headers like this in ~4 years of using this
parser.
> - Tabulators are also allowed.
>
> I suggest:
> message_header = ((field_name [ \t]* ":" [ \t]*
> field_value)|value_cont) :> CRLF;
I just pushed this out to unicorn.git to allow horizontal tabs:
>From 935912a422cabfd323f9b4ff268ded09a2ebe7a6 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Fri, 7 May 2010 18:20:49 +0000
Subject: [PATCH] http: allow horizontal tab as leading whitespace in header values
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This is allowed by RFC 2616, section 2.2, where spaces and
horizontal tabs are counted as linear white space and linear
white space (not just regular spaces) may prefix field-values
(section 4.2).
This has _not_ been a real issue in ~4 years of using this
parser (starting with Mongrel) with clients in the wild.
Thanks to Iñaki Baz Castillo for pointing this out.
---
ext/unicorn_http/unicorn_http_common.rl | 2 +-
test/unit/test_http_parser.rb | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/ext/unicorn_http/unicorn_http_common.rl b/ext/unicorn_http/unicorn_http_common.rl
index 6fca604..f165e3f 100644
--- a/ext/unicorn_http/unicorn_http_common.rl
+++ b/ext/unicorn_http/unicorn_http_common.rl
@@ -54,7 +54,7 @@
value_cont = lws+ any* >start_value %write_cont_value;
- message_header = ((field_name ":" " "* field_value)|value_cont) :> CRLF;
+ message_header = ((field_name ":" lws* field_value)|value_cont) :> CRLF;
chunk_ext_val = token*;
chunk_ext_name = token*;
chunk_extension = ( ";" " "* chunk_ext_name ("=" chunk_ext_val)? )*;
diff --git a/test/unit/test_http_parser.rb b/test/unit/test_http_parser.rb
index 5b0ca9f..b7c8a1c 100644
--- a/test/unit/test_http_parser.rb
+++ b/test/unit/test_http_parser.rb
@@ -51,6 +51,14 @@ class HttpParserTest < Test::Unit::TestCase
assert parser.keepalive?
end
+ def test_tab_lws
+ parser = HttpParser.new
+ req = {}
+ tmp = "GET / HTTP/1.1\r\nHost:\tfoo.bar\r\n\r\n"
+ assert_equal req.object_id, parser.headers(req, tmp).object_id
+ assert_equal "foo.bar", req['HTTP_HOST']
+ end
+
def test_connection_close_no_ka
parser = HttpParser.new
req = {}
--
[1] - and those were wild NSFW sites, of course :>
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 2%]
* Re: [ANN] unicorn 0.99.0 - simplicity wins
2010-05-06 20:49 0% ` Jamie Wilkinson
@ 2010-05-06 21:01 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-05-06 21:01 UTC (permalink / raw)
To: unicorn list
Jamie Wilkinson <jamie@internetfamo.us> wrote:
> Re: bundling/isolating:
>
> > If it is not possible to only have one Rack version installed
> > "globally", then they should either use Isolate or Bundler and
> > install a private version of Unicorn along with their preferred
> > version of Rack. Users who install in this way are recommended to
> > execute the isolated/bundled version of Unicorn, instead of what
> > would normally be in $PATH.
>
> A caveat about using a bundled unicorn binary (via `bundle exec
> unicorn`): if you use capistrano-based deployment, make sure to use a
> shared vendor/bundler_gems!
Thanks for the tip!
> Obviously this is much faster than re-bundling each release, but it
> also prevents the unicorn binary from going missing -- if unicorn is
> originally executed as
> /app/releases/XXY/vendor/bundler_gems/bin/unicorn and that release
> gets rolled back or pruned by :keep_releases, the original master's
> binary is now gone & it will no longer be able to fork new unicorn
> masters (is this expected behavior/a known issue?)
Yeah, Unicorn will stash the original command-line it was executed
with. If you need to override this at runtime, I would do something
like this in the Unicorn config file:
Unicorn::HttpServer::START_CTX[0] = "/some/path/to/bin/unicorn"
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: [ANN] unicorn 0.99.0 - simplicity wins
2010-05-06 19:37 5% [ANN] unicorn 0.99.0 - simplicity wins Eric Wong
@ 2010-05-06 20:49 0% ` Jamie Wilkinson
2010-05-06 21:01 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Jamie Wilkinson @ 2010-05-06 20:49 UTC (permalink / raw)
To: unicorn list
Re: bundling/isolating:
> If it is not possible to only have one Rack version installed
> "globally", then they should either use Isolate or Bundler and
> install a private version of Unicorn along with their preferred
> version of Rack. Users who install in this way are recommended
> to execute the isolated/bundled version of Unicorn, instead of
> what would normally be in $PATH.
A caveat about using a bundled unicorn binary (via `bundle exec unicorn`): if you use capistrano-based deployment, make sure to use a shared vendor/bundler_gems!
Obviously this is much faster than re-bundling each release, but it also prevents the unicorn binary from going missing -- if unicorn is originally executed as /app/releases/XXY/vendor/bundler_gems/bin/unicorn and that release gets rolled back or pruned by :keep_releases, the original master's binary is now gone & it will no longer be able to fork new unicorn masters (is this expected behavior/a known issue?)
-jamie
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* [ANN] unicorn 0.99.0 - simplicity wins
@ 2010-05-06 19:37 5% Eric Wong
2010-05-06 20:49 0% ` Jamie Wilkinson
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2010-05-06 19:37 UTC (permalink / raw)
To: mongrel-unicorn
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/
* mongrel-unicorn@rubyforge.org
* git://git.bogomips.org/unicorn.git
Changes:
Starting with this release, we'll always load Rack up front at
startup.
Previously we had complicated ways to avoid loading Rack until
after the application was loaded to allow the application to
load an alternate version of Rack. However this has proven too
error-prone to be worth supporting even though Unicorn does not
have strict requirements on currently released Rack versions.
If an app requires a different version of Rack than what Unicorn
would load by default, it is recommended they only install that
version of Rack (and no others) since Unicorn does not have any
strict requirements on currently released Rack versions.
Rails 2.3.x users should be aware of this as those versions are
not compatible with Rack 1.1.0.
If it is not possible to only have one Rack version installed
"globally", then they should either use Isolate or Bundler and
install a private version of Unicorn along with their preferred
version of Rack. Users who install in this way are recommended
to execute the isolated/bundled version of Unicorn, instead of
what would normally be in $PATH.
Feedback/tips to mailto:mongrel-unicorn@rubyforge.org from
Isolate and Bundler users would be greatly appreciated.
Thanks to Aaron Eisenberger for making us aware of this issue.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 5%]
* Re: funky process tree + stillborn masters
@ 2010-04-28 7:40 3% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-04-28 7:40 UTC (permalink / raw)
To: Jamie Wilkinson; +Cc: unicorn list
Jamie Wilkinson <jamie@tramchase.com> wrote:
> Update from the trenches: I've traced this down to the newrelic_rpm
> agent
>
> Noticed this is not the 1st time this has been brought up, since
> newrelic spins up the stats collector in its own thread.
>
> Attempted the (old) logger mutex monkeypatch mentioned in the unicorn
> docs without luck. Noodled with various permutations of
> NewRelic::Agent.shutdown in before/after_fork without success.
> NewRelic apparently has some compat issues with bundler, but that
> didn't affect it, nor did switching to the plugin.
>
> I'm running the latest newrelic_rpm agent (2.11.2) and the latest
> unicorn (0.97.1).
>
> I imagine this is contention over its logfile. Is there any
> low-hanging fruit I should try?
Hi Jamie, thanks for the follow up.
Exactly which version of Ruby + patchlevel are you using? Some of the
1.8.7 releases had threading bugs in them which you may be hitting:
http://redmine.ruby-lang.org/issues/show/1993
http://www.daniel-azuma.com/blog/view/z2ysbx0e4c3it9/ruby_1_8_7_io_select_threading_bug
But ...
> I've also filed a bug with NewRelic:
> http://support.newrelic.com/discussions/support/2577-newrelic-agentbundler-causing-stillborn-unicorn-processes?unresolve=true
> # straces show there's a bad file descriptor read -- presumably logfiles.
> # I've noodled with shutting down the agent in unicorn before/after forks
> # without a lot of luck. Tried newrelic as a plugin with the same issue,
> # as well as some of the bundler fixes mentioned in the FAQ, as well as
> # the
Now that we know it's NewRelic, I suspect it could be reading from the
agent's client socket, not a log file. You can map fd => files/sockets
with "ls -l /proc/$pid/fd" or "lsof -p $pid"
Perhaps in the before_fork hook you can try closing the TCPSocket (or
similar) that NewRelic is using. Merely stopping the agent thread
isn't guaranteed to close the client socket properly (in fact, I can
almost guaratee it won't close the socket at the OS level).
Since you're on Linux, try putting the output of "ls -l /proc/#$$/fd" or
"lsof -p #$$" in both the after_fork+before_fork hooks to get an idea of
which descriptors are open across forks.
> # Unicorn doesn't play very nicely with threads, are there are any other
> # manual setup/teardown methods beyond NewRelic::Agent.shutdown I could
> # try to get fd's closed properly between forks?
There's nothing inherent to Unicorn that prevents it from playing nicely
with threads. It's just not playing nicely with threaded code written
without potential fork() calls in mind.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: funky process tree + stillborn masters
@ 2010-04-13 3:23 0% ` Jamie Wilkinson
0 siblings, 1 reply; 200+ results
From: Jamie Wilkinson @ 2010-04-13 3:23 UTC (permalink / raw)
To: unicorn list
Whew! After a long day of debugging, I think I've gotten closer to isolating this.
I've upgraded us to your pre-release gem but I can still get it working (both before & after a lot of the below fixes)
>> After a USR2 signal our process tree winds up looking like this, with
>> several master-esque processes listed as children (but without the
>> "worker[N]" label):
>>
>> app 14402 4.4 0.8 199612 70264 ? S 14:07 0:04 unicorn_rails master -c config/unicorn.rb -E production -D
>> app 14433 0.0 0.8 204540 68504 ? Sl 14:07 0:00 \_ unicorn_rails worker[0] -c config/unicorn.rb -E production -D
>> app 14435 0.0 0.8 204540 68508 ? Sl 14:07 0:00 \_ unicorn_rails worker[1] -c config/unicorn.rb -E production -D
>> app 14438 0.0 0.8 199748 65840 ? S 14:07 0:00 \_ /usr/bin/ruby1.8 /usr/bin/unicorn_rails -c config/unicorn.rb -E production -D
>> app 14440 0.0 0.8 204540 68508 ? Sl 14:07 0:00 \_ unicorn_rails worker[3] -c config/unicorn.rb -E production -D
>> app 14442 0.0 0.8 204540 68508 ? Sl 14:07 0:00 \_ unicorn_rails worker[4] -c config/unicorn.rb -E production -D
>> app 14445 0.0 0.8 199760 65840 ? S 14:07 0:00 \_ /usr/bin/ruby1.8 /usr/bin/unicorn_rails -c config/unicorn.rb -E production -D
>> app 14447 0.0 0.8 204540 68508 ? Sl 14:07 0:00 \_ unicorn_rails worker[6] -c config/unicorn.rb -E production -D
>> app 14449 0.0 0.8 204780 69272 ? Sl 14:07 0:00 \_ unicorn_rails worker[7] -c config/unicorn.rb -E production -D
>>
>> Sending another USR2 signal will bring a new master into the mix as a
>> child, spins up a single child worker of its own (which also resembles
>> the "/usr/bin/ruby1.8" master-esque processes), and then fails to
>> continue.
>
> Anything in your before_fork/after_fork hooks? Since it looks like
> you're on a Linux system, can you strace the master while you send
> it a USR2 and see if anything strange happens?
The only real contents of our before_hook is a send-QUIT-on-first-worker, which I swapped out for the default SIGTTOU behavior. No change.
> I assume you're using regular "unicorn" to run your Sinatra apps and not
> "unicorn_rails". I made some largish cleanups to both for the 0.97.0
> release and and perhaps some bugs slipped into the "_rails" variant.
>
> Not sure if it's a problem, but with Bundler I assume Rack itself is a
> bundled dependency, but you're starting unicorn_rails out of
> /usr/bin/unicorn_rails which indicates Unicorn is not bundled (and won't
> use the bundled Rack). Can you ensure your unbundled Rack is the same
> version as the bundled one to be on the safe side?
>
My system & bundled rack versions match.
Swapped to vanilla "unicorn" instead of "unicorn_rails" -- also no dice
I switched to using "bundle exec unicorn", which uses RAILS_ROOT/vendor/bundler_gems/bin/unicorn instead of /usr/bin/unicorn. Was convinced this would be it, but no dice.
Attaching some relevant stack traces... the new "orphan" master & its 1st child are pretty boring while just hanging out:
Process 20738 attached - interrupt to quit
futex(0x2aaaaafb23c0, FUTEX_WAIT, 2, NULL
Sending a USR2 to the new, orphaned master...
Process 20738 attached - interrupt to quit
select(10, [9], [], [], {23, 661000}) = ? ERESTARTNOHAND (To be restarted)
--- SIGUSR2 (User defined signal 2) @ 0 (0) ---
rt_sigreturn(0xc) = -1 EINTR (Interrupted system call)
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
clock_gettime(CLOCK_MONOTONIC, {2782804, 359708496}) = 0
select(0, [], [], [], {0, 0}) = 0 (Timeout)
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
fcntl(5, F_GETFL) = 0x801 (flags O_WRONLY|O_NONBLOCK)
write(5, "."..., 1) = 1
clock_gettime(CLOCK_MONOTONIC, {2782804, 360046496}) = 0
select(10, [9], [], [], {20, 464341}
I've also produced straces of the *original* master during USR2 restarts, both a success trace and a failure trace.
Here's a tarball with both complete traces as well as filtered/grepp'd ones:
http://jamiedubs.com/files/unicorn-strace.tgz
I've also found that kill -9'ing the 1st worker of the new orphaned master allows it to continue operation as normal (spinning up workers and taking control from the original master) -- suggesting something is up with just that first worker (!). I'm going to keep noodling with before_/after_fork strategies.
-jamie
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: funky process tree + stillborn masters
2010-04-08 23:55 2% ` Eric Wong
@ 2010-04-09 1:20 2% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2010-04-09 1:20 UTC (permalink / raw)
To: unicorn list
Eric Wong <normalperson@yhbt.net> wrote:
> I assume you're using regular "unicorn" to run your Sinatra apps and not
> "unicorn_rails". I made some largish cleanups to both for the 0.97.0
> release and and perhaps some bugs slipped into the "_rails" variant.
<snip>
> Jamie Wilkinson <jamie@tramchase.com> wrote:
> > Are the goofy worker processes in the process tree a real problem, or
> > just a red herring?
>
> Not sure if it's a problem, but with Bundler I assume Rack itself is a
> bundled dependency, but you're starting unicorn_rails out of
> /usr/bin/unicorn_rails which indicates Unicorn is not bundled (and won't
> use the bundled Rack). Can you ensure your unbundled Rack is the same
> version as the bundled one to be on the safe side?
>
> I've yet to try bundler 0.9 (and have barely used earlier), but you can
> also try bundling Unicorn and using the bundled bin/unicorn(_rails)
> launchers instead to ensure a consistent environment.
>
> Unicorn currently ends up (auto)loading "rack/utils" before the
> application is loaded, maybe it could (auto)load it after the app is
> loaded for preload_app users.
Do the following two patches help? I've also pushed out a few
cleanups to unicorn.git and also put up a prerelease gem at:
http://unicorn.bogomips.org/files/gems/unicorn-0.97.0.7.g22e3.gem
Shortlog of changes since 0.97.0:
Eric Wong (7):
tests: fix to run under Ruby 1.9.2dev
KNOWN_ISSUES: document Array#shuffle / Array#sample issue under 1.9
unicorn_rails: use TOPLEVEL_BINDING for eval
unicorn_rails: respect user's encoding in config.ru in 1.9
unicorn_rails: rename variable for consistency
bin/*: remove unnecessary listeners variable
unicorn: load constants after app has loaded
>From e1a72d58add4260feb6da56d9d588270173da74f Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Thu, 8 Apr 2010 17:10:46 -0700
Subject: [PATCH] unicorn_rails: use TOPLEVEL_BINDING for eval
This is to ensure there are no namespace inconsistencies
---
bin/unicorn_rails | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/bin/unicorn_rails b/bin/unicorn_rails
index 37ee027..de2361e 100755
--- a/bin/unicorn_rails
+++ b/bin/unicorn_rails
@@ -148,7 +148,7 @@ def rails_builder(config, daemonize)
when /\.ru$/
raw = File.open(config, "rb") { |fp| fp.sysread(fp.stat.size) }
raw.sub!(/^__END__\n.*/, '')
- eval("Rack::Builder.new {(#{raw}\n)}.to_app", nil, config)
+ eval("Rack::Builder.new {(#{raw}\n)}.to_app", TOPLEVEL_BINDING, config)
else
require config
Object.const_get(File.basename(config, '.rb').capitalize)
--
>From 22e3ed4de0e89b97dac91c95c796eb8a7f93e5de Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Thu, 8 Apr 2010 18:05:43 -0700
Subject: [PATCH] unicorn: load constants after app has loaded
This will help ensure we use the same version of Rack the
application uses and avoid loading conflicting/incompatible
versions.
---
lib/unicorn.rb | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/unicorn.rb b/lib/unicorn.rb
index b63abeb..75ce09d 100644
--- a/lib/unicorn.rb
+++ b/lib/unicorn.rb
@@ -800,15 +800,15 @@ module Unicorn
def build_app!
if app.respond_to?(:arity) && app.arity == 0
- # exploit COW in case of preload_app. Also avoids race
- # conditions in Rainbows! since load/require are not thread-safe
- Unicorn.constants.each { |x| Unicorn.const_get(x) }
-
if defined?(Gem) && Gem.respond_to?(:refresh)
logger.info "Refreshing Gem list"
Gem.refresh
end
self.app = app.call
+
+ # exploit COW in case of preload_app. Also avoids race
+ # conditions in Rainbows! since load/require are not thread-safe
+ Unicorn.constants.each { |x| Unicorn.const_get(x) }
end
end
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 2%]
* Re: funky process tree + stillborn masters
@ 2010-04-08 23:55 2% ` Eric Wong
2010-04-09 1:20 2% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Eric Wong @ 2010-04-08 23:55 UTC (permalink / raw)
To: unicorn list
Jamie Wilkinson <jamie@tramchase.com> wrote:
> Since upgrading bundler (but applying the RUBYOPT path fixes) we've
> started experiencing intermittent, difficult-to-isolate USR2 restart
> failures.
>
> After a USR2 signal our process tree winds up looking like this, with
> several master-esque processes listed as children (but without the
> "worker[N]" label):
>
> app 14402 4.4 0.8 199612 70264 ? S 14:07 0:04 unicorn_rails master -c config/unicorn.rb -E production -D
> app 14433 0.0 0.8 204540 68504 ? Sl 14:07 0:00 \_ unicorn_rails worker[0] -c config/unicorn.rb -E production -D
> app 14435 0.0 0.8 204540 68508 ? Sl 14:07 0:00 \_ unicorn_rails worker[1] -c config/unicorn.rb -E production -D
> app 14438 0.0 0.8 199748 65840 ? S 14:07 0:00 \_ /usr/bin/ruby1.8 /usr/bin/unicorn_rails -c config/unicorn.rb -E production -D
> app 14440 0.0 0.8 204540 68508 ? Sl 14:07 0:00 \_ unicorn_rails worker[3] -c config/unicorn.rb -E production -D
> app 14442 0.0 0.8 204540 68508 ? Sl 14:07 0:00 \_ unicorn_rails worker[4] -c config/unicorn.rb -E production -D
> app 14445 0.0 0.8 199760 65840 ? S 14:07 0:00 \_ /usr/bin/ruby1.8 /usr/bin/unicorn_rails -c config/unicorn.rb -E production -D
> app 14447 0.0 0.8 204540 68508 ? Sl 14:07 0:00 \_ unicorn_rails worker[6] -c config/unicorn.rb -E production -D
> app 14449 0.0 0.8 204780 69272 ? Sl 14:07 0:00 \_ unicorn_rails worker[7] -c config/unicorn.rb -E production -D
> Sending another USR2 signal will bring a new master into the mix as a
> child, spins up a single child worker of its own (which also resembles
> the "/usr/bin/ruby1.8" master-esque processes), and then fails to
> continue.
Hi Jamie,
Odd, if I had to guess PIDs 14438 and 14445 are actually worker[2] and
worker[5] based on the PIDs relative to other workers. So the new
master died right away, which really should've been logged...
> Further USR2 restarts will obviously do nothing, and we're forced to
> either kill -9 the stillborn master or cold-restart all of the
> unicorns. Nothing out of the ordinary is dumped to stderr or stdout
Anything in your before_fork/after_fork hooks? Since it looks like
you're on a Linux system, can you strace the master while you send
it a USR2 and see if anything strange happens?
Also, can you strace the weird looking processes above and see if
they're doing anything?
> Starting unicorns fresh produces a nice process list where every child
> is listed cleanly as "unicorn_rails worker[N]"
>
> We only have this issue in one of our applications, on a machine that
> has 1 Rails app & 2 Sinatra apps, all powered by nginx+unicorn. We've
> also only noticed this since upgrading to bundler from bundler08
I assume you're using regular "unicorn" to run your Sinatra apps and not
"unicorn_rails". I made some largish cleanups to both for the 0.97.0
release and and perhaps some bugs slipped into the "_rails" variant.
Can you try regular "unicorn" with a config.ru for Rails? I've stolen
this from the Rainbows! FAQ (http://rainbows.rubyforge.org/FAQ.html):
For Rails 2.3.x and later, the following config.ru will work for you:
ENV["RAILS_ENV"] ||= ENV["RACK_ENV"]
require "config/environment"
use Rails::Rack::Static
run ActionController::Dispatcher.new
For older versions of Rails, the following config.ru will work:
ENV["RAILS_ENV"] ||= ENV["RACK_ENV"]
require 'config/boot'
require 'config/environment'
require 'unicorn/app/old_rails'
require 'unicorn/app/old_rails/static' # not needed with Unicorn 0.95+
use Unicorn::App::OldRails::Static
run Unicorn::App::OldRails.new
One thing to watch out for is that RAILS_ENV will not be set in the
environment for you, thus we set it to match RACK_ENV.
> Are the goofy worker processes in the process tree a real problem, or
> just a red herring?
Not sure if it's a problem, but with Bundler I assume Rack itself is a
bundled dependency, but you're starting unicorn_rails out of
/usr/bin/unicorn_rails which indicates Unicorn is not bundled (and won't
use the bundled Rack). Can you ensure your unbundled Rack is the same
version as the bundled one to be on the safe side?
I've yet to try bundler 0.9 (and have barely used earlier), but you can
also try bundling Unicorn and using the bundled bin/unicorn(_rails)
launchers instead to ensure a consistent environment.
Unicorn currently ends up (auto)loading "rack/utils" before the
application is loaded, maybe it could (auto)load it after the app is
loaded for preload_app users.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: Issue with unicorn not starting via bluepill?
2010-03-18 21:12 3% Issue with unicorn not starting via bluepill? James Cox
@ 2010-03-19 8:26 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-03-19 8:26 UTC (permalink / raw)
To: unicorn list; +Cc: James Cox, ghazel
James Cox <james@imaj.es> wrote:
> trying to start my unicorn via bluepill, and running into this :
>
> Starting unicorn...\n{:unicorn_options=>
> {:config_file=>"/home/configs/unicorn/marketing.rb", :listeners=>[]},
> :daemonize=>true,
> :app=>
> #<Proc:0x000000001042c718@/usr/local/rvm/gems/ree-1.8.7-2010.01/gems/unicorn-0.97.0/bin/unicorn_rails:120>}
> Exception `Errno::EEXIST' at
> /usr/local/rvm/rubies/ree-1.8.7-2010.01/lib/ruby/1.8/fileutils.rb:243
> - File exists - tmp/cache
> Exception `Errno::EEXIST' at
> /usr/local/rvm/rubies/ree-1.8.7-2010.01/lib/ruby/1.8/fileutils.rb:243
> - File exists - tmp/pids
> Exception `Errno::EEXIST' at
> /usr/local/rvm/rubies/ree-1.8.7-2010.01/lib/ruby/1.8/fileutils.rb:243
> - File exists - tmp/sessions
> Exception `Errno::EEXIST' at
> /usr/local/rvm/rubies/ree-1.8.7-2010.01/lib/ruby/1.8/fileutils.rb:243
> - File exists - tmp/sockets
> Exception `EOFError' at
> /usr/local/rvm/gems/ree-1.8.7-2010.01/gems/unicorn-0.97.0/lib/unicorn/launcher.rb:45
> - end of file reached
> master failed to start, check stderr log for details
>
>
> it's a rather complicated setup etc, but essentially i've got bluepill
> instructing a start script which sets the right version of ruby just
> before hand (i.e. the rvm stuff).
>
> I can run it manually by going into the RAILS_ROOT and running it, but
> trying to run via bluepill explodes.
>
> any ideas?
I'm not familiar with Bluepill, it's a process monitor of some
sort. Both you and Greg are using unicorn_rails which did get
some overhauling in Unicorn 0.97.0. Everything seems fine on
my end, but maybe there's a piece of the puzzle I'm overlooking..
I'll dig further.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Issue with unicorn not starting via bluepill?
@ 2010-03-18 21:12 3% James Cox
2010-03-19 8:26 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: James Cox @ 2010-03-18 21:12 UTC (permalink / raw)
To: mongrel-unicorn
trying to start my unicorn via bluepill, and running into this :
Starting unicorn...\n{:unicorn_options=>
{:config_file=>"/home/configs/unicorn/marketing.rb", :listeners=>[]},
:daemonize=>true,
:app=>
#<Proc:0x000000001042c718@/usr/local/rvm/gems/ree-1.8.7-2010.01/gems/unicorn-0.97.0/bin/unicorn_rails:120>}
Exception `Errno::EEXIST' at
/usr/local/rvm/rubies/ree-1.8.7-2010.01/lib/ruby/1.8/fileutils.rb:243
- File exists - tmp/cache
Exception `Errno::EEXIST' at
/usr/local/rvm/rubies/ree-1.8.7-2010.01/lib/ruby/1.8/fileutils.rb:243
- File exists - tmp/pids
Exception `Errno::EEXIST' at
/usr/local/rvm/rubies/ree-1.8.7-2010.01/lib/ruby/1.8/fileutils.rb:243
- File exists - tmp/sessions
Exception `Errno::EEXIST' at
/usr/local/rvm/rubies/ree-1.8.7-2010.01/lib/ruby/1.8/fileutils.rb:243
- File exists - tmp/sockets
Exception `EOFError' at
/usr/local/rvm/gems/ree-1.8.7-2010.01/gems/unicorn-0.97.0/lib/unicorn/launcher.rb:45
- end of file reached
master failed to start, check stderr log for details
it's a rather complicated setup etc, but essentially i've got bluepill
instructing a start script which sets the right version of ruby just
before hand (i.e. the rvm stuff).
I can run it manually by going into the RAILS_ROOT and running it, but
trying to run via bluepill explodes.
any ideas?
Thanks,
James
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Newbie problems
2010-03-16 10:09 2% Newbie problems Matt Davies
@ 2010-03-16 18:10 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-03-16 18:10 UTC (permalink / raw)
To: unicorn list
Matt Davies <mjdavies@glam.ac.uk> wrote:
> Hello everyone
>
> I'm trying out Unicorn at the moment, I've used nginx and passenger extensively for some time now but I fancy a change :-).
>
> Here's the specs
>
> nginx version: nginx/0.7.65
> ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin10.2.0]
> unicorn (0.97.0)
> rails 2.3.5
> bundler 0.9.7
>
> When I run unicorn_rails from within the app root it all starts fine, and nginx proxies the requests over to unicorn, all hunky dorey.
>
> But, I can't get unicorn to start properly with a config file, even if the file is empty.
>
> Here's the error I'm getting back when trying to start unicorn_rails
>
> sudo unicorn_rails -c /path/to/unicorn.rb -E production -D -d
> {:app=>
> #<Proc:0x000000010118dd80@/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.97.0/bin/unicorn_rails:120>,
> :unicorn_options=>
> {:config_file=>"/path/to/unicorn.rb",
> :listeners=>[]},
> :daemonize=>true}
> Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/cache
> Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/pids
> Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/sessions
> Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/sockets
> Exception `EOFError' at /usr/local/lib/ruby/gems/1.8/gems/unicorn-0.97.0/lib/unicorn/launcher.rb:45 - end of file reached
> master failed to start, check stderr log for details
Hi Matt,
Was there anything else in the stderr output? Does starting
unicorn_rails without "-D" work (or show you more info)? Daemonizing
will redirect stderr to /dev/null unless you explicitly set
"stderr_path" in your config file.
> I've switched logging on in the config file like so
>
> logger Logger.new("log/unicorn.log")
>
> all that shows in that log is
>
> I, [2010-03-16T10:01:08.250818 #1824] INFO -- : listening on addr=0.0.0.0:8080 fd=5
If your application fails to load, the application probably spews
the error messages to stderr instead of the Unicorn logger, which
is only for Unicorn-only messages.
> Nginx however is throwing this error
>
> 2010/03/16 09:21:42 [error] 1539#0: *1 kevent() reported that connect() failed (61: Connection refused) while connecting to upstream, client: ipaddress, server: machinename, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8080/", host: "machinename"
Try getting more info out of stderr first, since there appears to
be a problem with the startup.
But after that, what happens when you hit http://127.0.0.1:8080/ with
curl from that host?
> I'm sure I must be doing something very silly, I've searched the mailing list but can't find anything that is specific to this issue.
No worries. Also, if you leave out the -D switch, you can try
truss/strace/dtrace-ing the process if you still don't get enough
information.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Newbie problems
@ 2010-03-16 10:09 2% Matt Davies
2010-03-16 18:10 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Matt Davies @ 2010-03-16 10:09 UTC (permalink / raw)
To: mongrel-unicorn
Hello everyone
I'm trying out Unicorn at the moment, I've used nginx and passenger extensively for some time now but I fancy a change :-).
Here's the specs
nginx version: nginx/0.7.65
ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin10.2.0]
unicorn (0.97.0)
rails 2.3.5
bundler 0.9.7
When I run unicorn_rails from within the app root it all starts fine, and nginx proxies the requests over to unicorn, all hunky dorey.
But, I can't get unicorn to start properly with a config file, even if the file is empty.
Here's the error I'm getting back when trying to start unicorn_rails
sudo unicorn_rails -c /path/to/unicorn.rb -E production -D -d
{:app=>
#<Proc:0x000000010118dd80@/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.97.0/bin/unicorn_rails:120>,
:unicorn_options=>
{:config_file=>"/path/to/unicorn.rb",
:listeners=>[]},
:daemonize=>true}
Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/cache
Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/pids
Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/sessions
Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/sockets
Exception `EOFError' at /usr/local/lib/ruby/gems/1.8/gems/unicorn-0.97.0/lib/unicorn/launcher.rb:45 - end of file reached
master failed to start, check stderr log for details
I've switched logging on in the config file like so
logger Logger.new("log/unicorn.log")
all that shows in that log is
I, [2010-03-16T10:01:08.250818 #1824] INFO -- : listening on addr=0.0.0.0:8080 fd=5
Nginx however is throwing this error
2010/03/16 09:21:42 [error] 1539#0: *1 kevent() reported that connect() failed (61: Connection refused) while connecting to upstream, client: ipaddress, server: machinename, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8080/", host: "machinename"
I'm sure I must be doing something very silly, I've searched the mailing list but can't find anything that is specific to this issue.
If anyone can help I'd be most appreciative.
Regards
Matt
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: feature request - when_ready() hook
@ 2010-03-08 22:58 2% ` Suraj Kurapati
0 siblings, 0 replies; 200+ results
From: Suraj Kurapati @ 2010-03-08 22:58 UTC (permalink / raw)
To: unicorn list
Hi Eric,
On Mon, Nov 30, 2009 at 3:47 PM, Suraj Kurapati wrote:
> from Capistrano, I send SIGUSR2 to the existing Unicorn master (which
> will become the old Unicorn master), wait 90 seconds, and then send
> SIGQUIT to the old Unicorn master. [...] The only thing I'm worried
> about is that I'll have to keep adjusting this timeout as the
> infrastructure my app depends upon becomes slower/faster. A
> when_ready() hook would really do wonders for me
Inspired by your solution[1] to a recent question about forking, I
solved this problem by temporarily sneaking into the build_app! method
and killing the old Unicorn master after the Rails app has been built:
before_fork do |server, worker|
#
# the following allows a new master process to incrementally
# phase out the old master process with SIGTTOU to avoid a
# thundering herd (especially in the "preload_app false" case)
# when doing a transparent upgrade. The last worker spawned
# will then kill off the old master process with a SIGQUIT.
#
old_pid_file = server.config[:pid].to_s + '.oldbin'
if File.exist? old_pid_file and
server.pid != old_pid_file and
worker.nr == server.worker_processes-1
then
#
# wait until Rails app is built and ready to serve (we do this by
# sneaking into Unicorn's build_app! method) by the last worker
# process inside the new Unicorn before stopping old Unicorn
#
orig_meth_name = :build_app!
orig_meth_impl = server.method(orig_meth_name)
server_metaclass = class << server; self; end
server_metaclass.class_eval do
# replace Unicorn's method with our own sneaky version
define_method orig_meth_name do
# behave like Unicorn's original method
orig_meth_impl.call
# do our sneaky business! (kill the old Unicorn)
begin
Process.kill :QUIT, File.read(old_pid_file).to_i
rescue Errno::ENOENT, Errno::ESRCH
# ignore
end
# restore Unicorn's original method
server_metaclass.class_eval do
define_method orig_meth_name, orig_meth_impl
end
end
end
end
end
Thanks for your help! :)
[1]: http://article.gmane.org/gmane.comp.lang.ruby.unicorn.general/425
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 2%]
* Re: Rails 3 "RAILS_ENV not defined by config/boot" error
@ 2010-02-18 23:36 7% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-02-18 23:36 UTC (permalink / raw)
To: unicorn list; +Cc: John Wulff
Eric Wong <normalperson@yhbt.net> wrote:
> John Wulff <johnwulff@gmail.com> wrote:
> > I'm running unicorn and unicorn-rails 0.96.1 and the latest Rails 3
> > beta gem. Firing up unicorn_rails spews "RAILS_ENV not defined by
> > config/boot". I know this is likely a result of RAILS_ROOT being
> > deprecated in Rails 3 but I can't seem to config my way around it.
> > I'm sure other people must have run into this before. Is there a
> > quick fix?
>
> Hi John,
>
> I haven't had a chance to look at Rails 3 yet, but you can probably try
> just using a plain config.ru with "unicorn" (not "unicorn_rails")
I've been planning on some large-ish changes in Unicorn 0.97.x to
bin/{unicorn,unicorn_rails} to make maintenance easier and fix
a few minor issues with the existing code.
Would the following change be enough to work with Rails 3
out-of-the-box?
diff --git a/bin/unicorn_rails b/bin/unicorn_rails
index b1458fc..4441c34 100755
--- a/bin/unicorn_rails
+++ b/bin/unicorn_rails
@@ -128,8 +128,6 @@ app = lambda do ||
rescue LoadError => err
abort "#$0 must be run inside RAILS_ROOT: #{err.inspect}"
end
- defined?(::RAILS_ROOT) or abort "RAILS_ROOT not defined by config/boot"
- defined?(::RAILS_ENV) or abort "RAILS_ENV not defined by config/boot"
defined?(::Rails::VERSION::STRING) or
abort "Rails::VERSION::STRING not defined by config/boot"
(I'll remember to test when I fix a few other things elsewhere)
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 7%]
* Re: "upstream timed out" after upgrades
@ 2010-02-04 20:23 3% ` John-Paul Bader
0 siblings, 0 replies; 200+ results
From: John-Paul Bader @ 2010-02-04 20:23 UTC (permalink / raw)
To: unicorn list
I can of course, however I'd rather have an off the shelf ruby version out of the ports tree.
But if there is currently no other way to fix this issue I will of course. I wonder if this issue always appears on ruby1.9. I will check that out too.
Kind regards, John
On 04.02.2010, at 21:14, Eric Wong wrote:
> John-Paul Bader <hukl@berlin.ccc.de> wrote:
>> Hmm I see, kind of ;)
>>
>> Do you have a clue what is going wrong or any other things I could
>> check out ?
>
> Can you just backport the r26253 change into your 1.8.7-p248
> installation? (see the patch in the previous email). I'm fairly
> certain that's it based on the EINVAL.
>
> --
> Eric Wong
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: "upstream timed out" after upgrades
@ 2010-02-04 8:48 1% ` John-Paul Bader
0 siblings, 1 reply; 200+ results
From: John-Paul Bader @ 2010-02-04 8:48 UTC (permalink / raw)
To: unicorn list
Hrm its getting weirder and weirder.
I started unicorn_rails now manually in the app root which is now running on rails 2.3.3 again:
sudo unicorn_rails -E production -d -c /usr/local/etc/unicorn.rb
Now first of all it throws lots of Exceptions it couldn't find several (important) gems and then it produces this every second or so:
Exception `Errno::EAGAIN' at /usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.3/lib/unicorn.rb:640 - Resource temporarily unavailable - accept(2)
When I request the javascript in question I get:
Exception `Errno::EINVAL' at /usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.3/lib/unicorn/http_response.rb:67 - Invalid argument
Exception `Errno::EAGAIN' at /usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.3/lib/unicorn.rb:640 - Resource temporarily unavailable - accept(2)
This is the same no matter if I run it with -c or not.
I am puzzled.
To give you the entire output of unicorn starting:
[hukl@cccms /usr/local/www/cccms]$ sudo unicorn_rails -E production -d -p 9090
{:daemonize=>false,
:unicorn_options=>{:listeners=>["0.0.0.0:9090"]},
:app=>
#<Proc:0x0000000801782388@/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.3/bin/unicorn_rails:124>}
Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/cache
Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/pids
Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/sessions
Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - tmp/sockets
I, [2010-02-04T09:42:08.141034 #38499] INFO -- : listening on addr=213.73.89.122:9090 fd=3
Exception `LoadError' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31 - no such file to load -- Win32API
Exception `LoadError' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:38 - no such file to load -- Win32API
I, [2010-02-04T09:42:08.158275 #38499] INFO -- : worker=0 spawning...
I, [2010-02-04T09:42:08.159352 #38499] INFO -- : master process ready
I, [2010-02-04T09:42:08.159471 #38501] INFO -- : worker=0 spawned pid=38501
I, [2010-02-04T09:42:08.197082 #38501] INFO -- : Refreshing Gem list
Exception `Gem::LoadError' at /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:827 - Could not find RubyGem builder (~> 2.1.2)
Exception `Gem::LoadError' at /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:827 - Could not find RubyGem memcache-client (>= 1.7.4)
Exception `Gem::LoadError' at /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:827 - Could not find RubyGem tzinfo (~> 0.3.12)
Exception `Gem::LoadError' at /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:827 - Could not find RubyGem i18n (~> 0.1.3)
Exception `TypeError' at (eval):4 - can't modify frozen object
Exception `MissingSourceFile' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31 - no such file to load -- fast_xs
Exception `MissingSourceFile' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31 - no such file to load -- json
Using c extension for JSON.
Exception `Gem::LoadError' at /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:827 - Could not find RubyGem tmail (~> 1.2.3)
Exception `MissingSourceFile' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31 - no such file to load -- tmail/tmailscanner
Exception `MissingSourceFile' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:38 - no such file to load -- tmail/tmailscanner
Exception `MissingSourceFile' at /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:162 - no such file to load -- tmail/tmailscanner
Exception `Gem::LoadError' at /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:827 - Could not find RubyGem activerecord-postgresql-adapter (>= 0)
Exception `MissingSourceFile' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31 - no such file to load -- pg
WARNING: Nokogiri was built against LibXML version 2.7.3, but has dynamically loaded 2.7.6
Exception `MissingSourceFile' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31 - no such file to load -- ruby-debug
Exception `MissingSourceFile' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31 - no such file to load -- classtree
Exception `MissingSourceFile' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:38 - no such file to load -- classtree
Exception `MissingSourceFile' at /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:162 - no such file to load -- classtree
Exception `MissingSourceFile' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31 - no such file to load -- methodsig
Exception `MissingSourceFile' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:38 - no such file to load -- methodsig
Exception `MissingSourceFile' at /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:162 - no such file to load -- methodsig
=> Debugger enabled
worker=0 ready
Exception `Errno::EAGAIN' at /usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.3/lib/unicorn.rb:640 - Resource temporarily unavailable - accept(2)
Exception `Errno::EINVAL' at /usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.3/lib/unicorn/http_response.rb:67 - Invalid argument
Exception `Errno::EAGAIN' at /usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.3/lib/unicorn.rb:640 - Resource temporarily unavailable - accept(2)
Exception `Errno::EINVAL' at /usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.3/lib/unicorn/http_response.rb:67 - Invalid argument
Exception `Errno::EAGAIN' at /usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.3/lib/unicorn.rb:640 - Resource temporarily unavailable - accept(2)
Exception `Errno::EINVAL' at /usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.3/lib/unicorn/http_response.rb:67 - Invalid argument
Exception `Errno::EAGAIN' at /usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.3/lib/unicorn.rb:640 - Resource temporarily unavailable - accept(2)
I seriously have no idea went wrong - It ran all so smooth couple of days ago. What am I missing - there must be something plain wrong. I left the js files out of the public site for now - it isn't needed that much and its more important to serve the content for now. In case you are trying to get it.
Kind regards, John
On 04.02.2010, at 09:16, John-Paul Bader wrote:
> Hey guys,
>
>
> i recently updated several components of my website setup:
>
> varnish 2.0.5 -> 2.0.6
> nginx 7.4.2 -> 7.4.5
> unicorn 0.95.3 -> 0.96
> ruby18 to the latest patch level
> and rails from 2.3.2
>
> It all seemed to work great but recently I noticed that the website hangs loading. The weird thing is that it hangs because 2 or 3 javascript files take about a minute to finish and when they do they are incomplete as in cut of in the middle of the content. The nginx error log gives the following output every few seconds:
>
> 2010/02/04 08:58:41 [error] 29389#0: *471 upstream timed out (60: Operation timed out) while reading upstream, client: 213.73.89.122, server: www.ccc.de, request: "GET /javascripts/jquery-1.3.2.min.js?1246657683 HTTP/1.1", upstream: "http://unix:/var/run/unicorn.sock:/javascripts/jquery-1.3.2.min.js?1246657683", host: "www.ccc.de"
>
> I don't think its varnishs fault because i get Internal Server Errors (500) if I run curl on the machine against nginx, not at first though - several requests for that jquery file run just fine and then suddenly i get a 500 on a request with the content being cut of in the middle.
>
> Next thing I did was configuring unicorn to listen on 213.73.89.122:9090 rather than on a socket so i could run curl directly against it and even after a fresh start of unicorn gives me:
>
>
> curl http://213.73.89.122:9090/javascripts/jquery-1.3.2.min.js
> (lots of javascript)…,rowspan:"rowSpan",tabindex:"tabIndHTTP/1.1 500 Internal Server Error
>
> curl: (18) transfer closed with 16256 bytes remaining to read
>
> I also downgraded back to 0.95.3 but that didn't change anything. So now after 8h of try and error I'm out of ideas and would be happy to hear some suggestions.
>
> Kind regards, John
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 1%]
* Re: Getting a strange cookie error
2010-01-22 23:29 3% ` Travis Bell
@ 2010-01-28 22:19 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-01-28 22:19 UTC (permalink / raw)
To: unicorn list
Travis Bell <travis@meticulo.com> wrote:
> Hi Eric,
>
> Thanks for looking into this. I'll strip down my app and do a similar
> "Hello World" version and see how I make out. I will give that method
> of loading Thin a try too.
>
> Report back when I know more.
Hi Travis (or anybody else listening), any updates/info on this issue?
Thanks!
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* [PATCH] KNOWN_ISSUES: background threads + Logger monkey patch
@ 2010-01-26 2:35 4% Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-01-26 2:35 UTC (permalink / raw)
To: mongrel-unicorn
Thanks to Michael Guterl for informing us of the issues
and testing the monkey patch.
---
Pushed out to the website and unicorn.git
KNOWN_ISSUES | 8 ++++++++
examples/logger_mp_safe.rb | 25 +++++++++++++++++++++++++
2 files changed, 33 insertions(+), 0 deletions(-)
create mode 100644 examples/logger_mp_safe.rb
diff --git a/KNOWN_ISSUES b/KNOWN_ISSUES
index 83b3584..e83e34e 100644
--- a/KNOWN_ISSUES
+++ b/KNOWN_ISSUES
@@ -3,6 +3,14 @@
Occasionally odd {issues}[link:ISSUES.html] arise without a transparent or
acceptable solution. Those issues are documented here.
+* When using "preload_app true", with apps using background threads
+ need to restart them in the after_fork hook because threads are never
+ shared with child processes. Additionally, any synchronization
+ primitives (Mutexes, Monitors, ConditionVariables) should be
+ reinitialized in case they are held during fork time to avoid
+ deadlocks. The core Ruby Logger class needlessly uses a MonitorMutex
+ which can be disabled with a {monkey patch}[link:examples/logger_mp_safe.rb]
+
* Rails 2.3.2 bundles its own version of Rack. This may cause subtle
bugs when simultaneously loaded with the system-wide Rack Rubygem
which Unicorn depends on. Upgrading to Rails 2.3.4 (or later) is
diff --git a/examples/logger_mp_safe.rb b/examples/logger_mp_safe.rb
new file mode 100644
index 0000000..05ad3fa
--- /dev/null
+++ b/examples/logger_mp_safe.rb
@@ -0,0 +1,25 @@
+# Multi-Processing-safe monkey patch for Logger
+#
+# This monkey patch fixes the case where "preload_app true" is used and
+# the application spawns a background thread upon being loaded.
+#
+# This removes all lock from the Logger code and solely relies on the
+# underlying filesystem to handle write(2) system calls atomically when
+# O_APPEND is used. This is safe in the presence of both multiple
+# threads (native or green) and multiple processes when writing to
+# a filesystem with POSIX O_APPEND semantics.
+#
+# It should be noted that the original locking on Logger could _never_ be
+# considered reliable on non-POSIX filesystems with multiple processes,
+# either, so nothing is lost in that case.
+
+require 'logger'
+class Logger::LogDevice
+ def write(message)
+ @dev.syswrite(message)
+ end
+
+ def close
+ @dev.close
+ end
+end
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 4%]
* Re: Getting a strange cookie error
@ 2010-01-22 23:29 3% ` Travis Bell
2010-01-28 22:19 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Travis Bell @ 2010-01-22 23:29 UTC (permalink / raw)
To: mongrel-unicorn
Hi Eric,
Thanks for looking into this. I'll strip down my app and do a similar "Hello World" version and see how I make out. I will give that method of loading Thin a try too.
Report back when I know more.
Thanks!
--
Travis Bell
On 2010-01-22, at 1:06 PM, Travis Bell wrote:
> Just a follow up, it looks like it was rack 1.1.0 causing the issues. I uninstalled it, and am now using rack 1.0.1 and the error has gone away.
>
> Why it worked with Thin + Rack 1.1.0 and not Unicorn, still not sure.
>
>
> Cheers guys.
>
> --
> Travis Bell
> http://www.twitter.com/travisbell
> http://www.twitter.com/themoviedb
>
>
>
> On 2010-01-21, at 11:30 PM, Travis Bell wrote:
>
>> Hey guys,
>>
>> I've been developing with Thin since day 1 (many months) and today, as I started moving everything to test on production (with Unicorn) started getting this weird error.
>>
>> I am using Sinatra, and have been setting my cookies like so:
>>
>> response.set_cookie('foo', {
>> :value => "bar",
>> :path => '/',
>> :expires => Time.today+14400
>> })
>>
>> In Thin, Webrick, Passenger, this seems to work fine. However in Unicorn I get a big fat ugly error:
>>
>> # Rack::Lint::LintError at /login
>> # a header value must be a String, but the value of 'Set-Cookie' is a Array
>> # /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/rack-1.1.0/lib/rack/lint.rb: in assert, line 18
>>
>> I'm not really sure what this means since :value is a string. I am using the following versions:
>>
>> - REE (1.8.7-2010.01)
>> - Rack 1.1.0
>> - Unicorn 0.96.0
>> - Latest Sinatra from source
>>
>> Does anyone have any input as to why this is happening? I have been able to re-produce this on a 32-bit CentOS box and my local MacBook Pro (Snow Leopard).
>>
>>
>> Cheers,
>>
>> --
>> Travis Bell
>> http://www.twitter.com/travisbell
>> http://www.twitter.com/themoviedb
>>
>>
>>
>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Unicorn can't find gems?
2010-01-19 21:42 3% Unicorn can't find gems? Steve Klabnik
2010-01-19 21:48 3% ` Eric Wong
@ 2010-01-19 21:56 4% ` David Palm
1 sibling, 0 replies; 200+ results
From: David Palm @ 2010-01-19 21:56 UTC (permalink / raw)
To: unicorn list
> Missing the Rails 2.3.5 gem. Please `gem install -v=2.3.5 rails`,
> update your RAILS_GEM_VERSION setting in config/environment.rb for the
> Rails version you do have installed, or comment out RAILS_GEM_VERSION
> to use the latest version installed.
I think I know what this is.
I went nuts on this today. It's Rack 1.1 that is messing with you and stupid stupid rails that, in boot.rb has this:
rescue Gem::LoadError => load_error
$stderr.puts %(Missing the Rails #{version} gem. Please `gem install -v=#{version} rails`... ...
end
Rails assumes the only reason for failure is a missing Rails install, but if you throw in a #{load_error.inspect} in there the Rack issue shows up loud and clear...
Always always include the actual error in a log statement when you rescue!
:)
> Exception `Errno::EAGAIN' at
> /opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/gems/1.8/gems/unicorn-0.96.0/lib/unicorn.rb:436
> - Resource temporarily unavailable
> I, [2010-01-19T21:25:09.918670 #30184] INFO -- : reaped
> #<Process::Status: pid=30185,exited(1)> worker=0
> Exception `Errno::ECHILD' at
> /opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/gems/1.8/gems/unicorn-0.96.0/lib/unicorn.rb:454
> - No child processes
>
> And then it just repeats.
>
> I'm using ree both locally and on the server (as you can see), but I'm
> using it through rvm locally.
>
> Any idea what this might be?
>
> Thanks,
> Steve
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 4%]
* Re: Unicorn 0.96 doesn't play nice with Rails 2.3.5
2010-01-11 22:27 4% Unicorn 0.96 doesn't play nice with Rails 2.3.5 Peter Kieltyka
2010-01-12 3:42 4% ` Eric Wong
@ 2010-01-19 21:50 0% ` Iñaki Baz Castillo
1 sibling, 0 replies; 200+ results
From: Iñaki Baz Castillo @ 2010-01-19 21:50 UTC (permalink / raw)
To: mongrel-unicorn
El Lunes, 11 de Enero de 2010, Peter Kieltyka escribió:
> The exception message in GemBoot tells me:
> can't activate rack (~> 1.0.0, runtime) for ["actionpack-2.3.5",
> "rails-2.3.5"], already activated rack-1.1.0 for ["unicorn-0.96.0"]
>
> So, I uninstalled rack 1.1.0, leaving behind just rack 1.0.1. Started up
> the unicorn_rails again and voila. The issue seemed to be a conflict with
> the rack 1.1 already being loaded by Unicorn, and when Rails begins to
> load and checks its dependencies, the rack version is too new for 2.3.5.
>
> I'm not sure what the fix is here, but uninstalling rack 1.1 probably is
> not the answer.
I think this bug is related to a recent thread:
http://www.mail-archive.com/mongrel-unicorn@rubyforge.org/msg00329.html
--
Iñaki Baz Castillo <ibc@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Unicorn can't find gems?
2010-01-19 21:42 3% Unicorn can't find gems? Steve Klabnik
@ 2010-01-19 21:48 3% ` Eric Wong
2010-01-19 21:56 4% ` David Palm
1 sibling, 0 replies; 200+ results
From: Eric Wong @ 2010-01-19 21:48 UTC (permalink / raw)
To: unicorn list
Steve Klabnik <steve@steveklabnik.com> wrote:
> Hello all. I've run into a strange problem with Unicorn, and Google
> couldn't help me out. Basically, I'm going to switch from Passenger to
> Unicorn for the next release of my Rails app. I installed it on my
> local machine, and it ran great. But then, as I was building my new
> server to deploy on, I ran into a snag.
>
> When I run 'unicorn_rails', I got a strange error. Here's the output
> of 'unicorn_rails -d' :
>
> $ unicorn_rails -d
<snip>
> Exception `Gem::LoadError' at
> /opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/site_ruby/1.8/rubygems.rb:280
> - can't activate rack (~> 1.0.0, runtime) for ["actionpack-2.3.5",
> "rails-2.3.5"], already activated rack-1.1.0 for ["unicorn-0.96.0"]
> Missing the Rails 2.3.5 gem. Please `gem install -v=2.3.5 rails`,
> update your RAILS_GEM_VERSION setting in config/environment.rb for the
> Rails version you do have installed, or comment out RAILS_GEM_VERSION
> to use the latest version installed.
> Exception `Errno::EAGAIN' at
> /opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/gems/1.8/gems/unicorn-0.96.0/lib/unicorn.rb:436
> - Resource temporarily unavailable
> I, [2010-01-19T21:25:09.918670 #30184] INFO -- : reaped
> #<Process::Status: pid=30185,exited(1)> worker=0
> Exception `Errno::ECHILD' at
> /opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/gems/1.8/gems/unicorn-0.96.0/lib/unicorn.rb:454
> - No child processes
>
> And then it just repeats.
>
> I'm using ree both locally and on the server (as you can see), but I'm
> using it through rvm locally.
>
> Any idea what this might be?
Hi Steve,
Rails 2.3.x isn't compatible with Rack 1.1.0. Unicorn depends on Rack
and since Unicorn is always loaded before Rails is, the Unicorn
dependency will always load the newest version of Rack on the system.
Uninstalling Rack 1.1.0 for now should fix things, just keep Rack 1.0.1
installed).
I'll add this to the FAQ for now, not sure if there's a sane solution
for it...
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Unicorn can't find gems?
@ 2010-01-19 21:42 3% Steve Klabnik
2010-01-19 21:48 3% ` Eric Wong
2010-01-19 21:56 4% ` David Palm
0 siblings, 2 replies; 200+ results
From: Steve Klabnik @ 2010-01-19 21:42 UTC (permalink / raw)
To: mongrel-unicorn
Hello all. I've run into a strange problem with Unicorn, and Google
couldn't help me out. Basically, I'm going to switch from Passenger to
Unicorn for the next release of my Rails app. I installed it on my
local machine, and it ran great. But then, as I was building my new
server to deploy on, I ran into a snag.
When I run 'unicorn_rails', I got a strange error. Here's the output
of 'unicorn_rails -d' :
$ unicorn_rails -d
{:daemonize=>false,
:unicorn_options=>{:listeners=>[]},
:app=>
#<Proc:0x000000000216dad0@/opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/gems/1.8/gems/unicorn-0.96.0/bin/unicorn_rails:124>}
Exception `Errno::EEXIST' at
/opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/1.8/fileutils.rb:243 -
File exists - tmp/cache
Exception `Errno::EEXIST' at
/opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/1.8/fileutils.rb:243 -
File exists - tmp/pids
Exception `Errno::EEXIST' at
/opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/1.8/fileutils.rb:243 -
File exists - tmp/sessions
Exception `Errno::EEXIST' at
/opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/1.8/fileutils.rb:243 -
File exists - tmp/sockets
I, [2010-01-19T21:25:09.748670 #30184] INFO -- : listening on
addr=0.0.0.0:8080 fd=3
Exception `LoadError' at
/opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31
- no such file to load -- Win32API
Exception `LoadError' at
/opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:38
- no such file to load -- Win32API
I, [2010-01-19T21:25:09.758670 #30184] INFO -- : worker=0 spawning...
I, [2010-01-19T21:25:09.768670 #30184] INFO -- : master process ready
I, [2010-01-19T21:25:09.768670 #30185] INFO -- : worker=0 spawned pid=30185
I, [2010-01-19T21:25:09.828670 #30185] INFO -- : Refreshing Gem list
Exception `Gem::LoadError' at
/opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/site_ruby/1.8/rubygems.rb:280
- can't activate rack (~> 1.0.0, runtime) for ["actionpack-2.3.5",
"rails-2.3.5"], already activated rack-1.1.0 for ["unicorn-0.96.0"]
Missing the Rails 2.3.5 gem. Please `gem install -v=2.3.5 rails`,
update your RAILS_GEM_VERSION setting in config/environment.rb for the
Rails version you do have installed, or comment out RAILS_GEM_VERSION
to use the latest version installed.
Exception `Errno::EAGAIN' at
/opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/gems/1.8/gems/unicorn-0.96.0/lib/unicorn.rb:436
- Resource temporarily unavailable
I, [2010-01-19T21:25:09.918670 #30184] INFO -- : reaped
#<Process::Status: pid=30185,exited(1)> worker=0
Exception `Errno::ECHILD' at
/opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/gems/1.8/gems/unicorn-0.96.0/lib/unicorn.rb:454
- No child processes
And then it just repeats.
I'm using ree both locally and on the server (as you can see), but I'm
using it through rvm locally.
Any idea what this might be?
Thanks,
Steve
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Issue when sending USR2 too soon
2010-01-18 11:25 3% ` Iñaki Baz Castillo
@ 2010-01-18 11:43 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-01-18 11:43 UTC (permalink / raw)
To: unicorn list
Iñaki Baz Castillo <ibc@aliax.net> wrote:
> El Lunes, 18 de Enero de 2010, Eric Wong escribió:
> > Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > > El Domingo, 17 de Enero de 2010, Iñaki Baz Castillo escribió:
> > > > What about if Unicorn very quicky prepares the trap for USR2 so in case
> > > > it receives it soon when starting it ignores it (and logs some
> > > > warning)? Does it make sense?
> > >
> > > Adding the following on the top of bin/unicorn solves the problem:
> > >
> > > # Ignore USR2 (instead of terminating script) in case it arrives too
> > > soon. trap("USR2") do
> > > $stderr.puts "WARN: USR2 signal (reload action) received too soon,
> > > ignored" end
> >
> > No it doesn't, it just reduces the window where signals aren't setup.
> > On systems where Unicorn is installed as a RubyGem, that window of time
> > may be much bigger.
>
> But note that I've added:
>
> trap("USR2") do
> $stderr.puts "WARN: USR2 signal (reload action) received too soon,
> ignored"
> end
>
> at the beginning of the executable, so the time window is really reduced. Also
> note that in my modified version of the executable I load many other gems and
> them make the unicorn loading slower, increasing the time window.
On systems with RubyGems, the executable is always an automatically
generated wrapper script that does "require 'rubygems'" first.
> > Is the issue with a script reading the pid file and sending the signal
> > because it exists?
>
> I've done a init script to start/stop/reload/log-rotate Unicorn. The action
> "log-rotate" takes the PID from the pid file and sends a USR1 (this call is
> made by logrotate). The action "reload" sends a USR2 and later a TERM
> (depending on if the PID has changed or not).
>
> I just want to avoid that, in case a user invokes "reload" twice too fast,
> Unicorn receives USR2 before preparing it so it dies. With my "hack" is more
> difficult such possibility to occur.
I'll look into what the consequences of writing the pid file after
signal handlers are setup later this week.
Unfortunately pid files are inherently racy for the USR2 case. Perhaps
your script can check the ctime of the pid file...
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Issue when sending USR2 too soon
@ 2010-01-18 11:25 3% ` Iñaki Baz Castillo
2010-01-18 11:43 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Iñaki Baz Castillo @ 2010-01-18 11:25 UTC (permalink / raw)
To: mongrel-unicorn
El Lunes, 18 de Enero de 2010, Eric Wong escribió:
> Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > El Domingo, 17 de Enero de 2010, Iñaki Baz Castillo escribió:
> > > What about if Unicorn very quicky prepares the trap for USR2 so in case
> > > it receives it soon when starting it ignores it (and logs some
> > > warning)? Does it make sense?
> >
> > Adding the following on the top of bin/unicorn solves the problem:
> >
> > # Ignore USR2 (instead of terminating script) in case it arrives too
> > soon. trap("USR2") do
> > $stderr.puts "WARN: USR2 signal (reload action) received too soon,
> > ignored" end
>
> No it doesn't, it just reduces the window where signals aren't setup.
> On systems where Unicorn is installed as a RubyGem, that window of time
> may be much bigger.
But note that I've added:
trap("USR2") do
$stderr.puts "WARN: USR2 signal (reload action) received too soon,
ignored"
end
at the beginning of the executable, so the time window is really reduced. Also
note that in my modified version of the executable I load many other gems and
them make the unicorn loading slower, increasing the time window.
> Is the issue with a script reading the pid file and sending the signal
> because it exists?
I've done a init script to start/stop/reload/log-rotate Unicorn. The action
"log-rotate" takes the PID from the pid file and sends a USR1 (this call is
made by logrotate). The action "reload" sends a USR2 and later a TERM
(depending on if the PID has changed or not).
I just want to avoid that, in case a user invokes "reload" twice too fast,
Unicorn receives USR2 before preparing it so it dies. With my "hack" is more
difficult such possibility to occur.
Thanks.
--
Iñaki Baz Castillo <ibc@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: Unicorn 0.96 doesn't play nice with Rails 2.3.5
2010-01-12 3:42 4% ` Eric Wong
@ 2010-01-12 14:36 0% ` Peter Kieltyka
0 siblings, 0 replies; 200+ results
From: Peter Kieltyka @ 2010-01-12 14:36 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
On 2010-01-11, at 10:42 PM, Eric Wong wrote:
> Peter Kieltyka <peter.kieltyka@gmail.com> wrote:
>> Hello,
>>
>> I've experienced a bug while trying to setup Unicorn 0.96.0 with my
>> Rails 2.3.5 app. Some details on my system: I'm running Freebsd 8.0-p2
>> (amd64) with Ruby 1.9.1 and Rubygems 1.3.5.
>>
>> Pretty much, I tried running "unicorn_rails" in the root of my rails
>> application, but it never loads. What happens is the master process
>> load then it keeps trying to start the worker app but fails. I kept
>> getting the message that I need to install Rails 2.3.5. At fist I
>> thought I had configured something incorrectly and there was a bad
>> reference to my gems, but no. The error message came from my Rails
>> config/boot.rb file which is called after the gem list has been
>> refreshed (via app.call in Unicorn). I traced through unicorn until I
>> found that in the load_rails_gem method of the GemBoot class was
>> raising the load error. When checking the exception message variable
>> it told me:
>>
>> $ unicorn_rails
>> I, [2010-01-11T16:20:11.330566 #23391] INFO -- : listening on addr=0.0.0.0:8080 fd=3
>> I, [2010-01-11T16:20:11.337793 #23391] INFO -- : worker=0 spawning...
>> I, [2010-01-11T16:20:11.339090 #23391] INFO -- : master process ready
>> I, [2010-01-11T16:20:11.339225 #23393] INFO -- : worker=0 spawned pid=23393
>> I, [2010-01-11T16:20:11.379570 #23393] INFO -- : Refreshing Gem list
>> Missing the Rails 2.3.5 gem. Please `gem install -v=2.3.5 rails`, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or comment out RAILS_GEM_VERSION to use the latest version installed.
>> I, [2010-01-11T16:20:11.446208 #23391] INFO -- : reaped #<Process::Status: pid 23393 exit 1> worker=0
>> I, [2010-01-11T16:20:11.446461 #23391] INFO -- : worker=0 spawning...
>> I, [2010-01-11T16:20:11.447539 #23394] INFO -- : worker=0 spawned pid=23394
>> I, [2010-01-11T16:20:11.488722 #23394] INFO -- : Refreshing Gem list
>> Missing the Rails 2.3.5 gem. Please `gem install -v=2.3.5 rails`, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or comment out RAILS_GEM_VERSION to use the latest version installed.
>> ... etc. ... keeps going on and on and on.
>>
>> The exception message in GemBoot tells me:
>>
>> can't activate rack (~> 1.0.0, runtime) for ["actionpack-2.3.5",
>> "rails-2.3.5"], already activated rack-1.1.0 for ["unicorn-0.96.0"]
>>
>> So, I uninstalled rack 1.1.0, leaving behind just rack 1.0.1. Started
>> up the unicorn_rails again and voila. The issue seemed to be a
>> conflict with the rack 1.1 already being loaded by Unicorn, and when
>> Rails begins to load and checks its dependencies, the rack version is
>> too new for 2.3.5.
>>
>> I'm not sure what the fix is here, but uninstalling rack 1.1 probably
>> is not the answer.
>
> Hi Peter,
>
> Uninstalling Rack 1.1 may be the best answer, especially
> if you don't need Rack for anything else.
>
> There are several problems at hand:
>
> 1. Rails 2.3.5 declares it is only compatible with Rack 1.0.x
> 2. Unicorn does not require any particular Rack version
> 3. RubyGems defaults to the latest version of any Gem if
> no version is explicitly specified.
>
> Since Unicorn is loaded before Rails, RubyGems will default to
> loading the latest version of Rack based on the Unicorn gemspec
>
> You have several other options here to work around this,
> they all suck (in no particular order of suckiness):
>
> 1. edit the installed Rails/active* gemspecs[1] so they're not
> pinned on on 1.0.x anymore (they *should* be compatible enough)
>
> 1a. vendorize Rails/active* and edit the gemspecs there
>
> 2. edit your copy of /path/to/unicorn_rails and
> activate Rack 1.0.x in there before Unicorn is activated
> (this is the "unicorn_rails" wrapper RubyGems creates for you,
> not the actual "unicorn_rails" source).
>
> 3. create a "vendored" copy of unicorn_rails for your
> application (script/my_unicorn) and activate Rack 1.0.x
> in there first.
>
> 4. install Unicorn using setup.rb without RubyGems
> (uninstalls/upgrades won't be as nice to deal with, though).
>
> 5. edit the installed Unicorn gemspec[1] to depend on Rack ~> 1.0
>
>
> [1] - RubyGems gemspecs are here:
> $prefix/lib/ruby/gems/$RUBY_VERSION/specifications/*.gemspec
>
> --
> Eric Wong
Hey Eric,
Thanks for the quick reply.
That is pretty much what I expected. I plan to begin experimenting with Rails 3 for this project in any regards but I thought I'd bring it to your attention if others have the same issue (which some already did acknowledge it on #rubyonrails@irc.freenode.net).
Strange though, on my OSX 10.6 system with the same setup (Ruby 1.9.1, Gems 1.3.5, Rack 1.1.0 & 1.0.1, and Unicorn 0.96.0) the issue doesn't come up. Ohh well..
Peter
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Unicorn 0.96 doesn't play nice with Rails 2.3.5
2010-01-11 22:27 4% Unicorn 0.96 doesn't play nice with Rails 2.3.5 Peter Kieltyka
@ 2010-01-12 3:42 4% ` Eric Wong
2010-01-12 14:36 0% ` Peter Kieltyka
2010-01-19 21:50 0% ` Iñaki Baz Castillo
1 sibling, 1 reply; 200+ results
From: Eric Wong @ 2010-01-12 3:42 UTC (permalink / raw)
To: Peter Kieltyka; +Cc: unicorn list
Peter Kieltyka <peter.kieltyka@gmail.com> wrote:
> Hello,
>
> I've experienced a bug while trying to setup Unicorn 0.96.0 with my
> Rails 2.3.5 app. Some details on my system: I'm running Freebsd 8.0-p2
> (amd64) with Ruby 1.9.1 and Rubygems 1.3.5.
>
> Pretty much, I tried running "unicorn_rails" in the root of my rails
> application, but it never loads. What happens is the master process
> load then it keeps trying to start the worker app but fails. I kept
> getting the message that I need to install Rails 2.3.5. At fist I
> thought I had configured something incorrectly and there was a bad
> reference to my gems, but no. The error message came from my Rails
> config/boot.rb file which is called after the gem list has been
> refreshed (via app.call in Unicorn). I traced through unicorn until I
> found that in the load_rails_gem method of the GemBoot class was
> raising the load error. When checking the exception message variable
> it told me:
>
> $ unicorn_rails
> I, [2010-01-11T16:20:11.330566 #23391] INFO -- : listening on addr=0.0.0.0:8080 fd=3
> I, [2010-01-11T16:20:11.337793 #23391] INFO -- : worker=0 spawning...
> I, [2010-01-11T16:20:11.339090 #23391] INFO -- : master process ready
> I, [2010-01-11T16:20:11.339225 #23393] INFO -- : worker=0 spawned pid=23393
> I, [2010-01-11T16:20:11.379570 #23393] INFO -- : Refreshing Gem list
> Missing the Rails 2.3.5 gem. Please `gem install -v=2.3.5 rails`, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or comment out RAILS_GEM_VERSION to use the latest version installed.
> I, [2010-01-11T16:20:11.446208 #23391] INFO -- : reaped #<Process::Status: pid 23393 exit 1> worker=0
> I, [2010-01-11T16:20:11.446461 #23391] INFO -- : worker=0 spawning...
> I, [2010-01-11T16:20:11.447539 #23394] INFO -- : worker=0 spawned pid=23394
> I, [2010-01-11T16:20:11.488722 #23394] INFO -- : Refreshing Gem list
> Missing the Rails 2.3.5 gem. Please `gem install -v=2.3.5 rails`, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or comment out RAILS_GEM_VERSION to use the latest version installed.
> ... etc. ... keeps going on and on and on.
>
> The exception message in GemBoot tells me:
>
> can't activate rack (~> 1.0.0, runtime) for ["actionpack-2.3.5",
> "rails-2.3.5"], already activated rack-1.1.0 for ["unicorn-0.96.0"]
>
> So, I uninstalled rack 1.1.0, leaving behind just rack 1.0.1. Started
> up the unicorn_rails again and voila. The issue seemed to be a
> conflict with the rack 1.1 already being loaded by Unicorn, and when
> Rails begins to load and checks its dependencies, the rack version is
> too new for 2.3.5.
>
> I'm not sure what the fix is here, but uninstalling rack 1.1 probably
> is not the answer.
Hi Peter,
Uninstalling Rack 1.1 may be the best answer, especially
if you don't need Rack for anything else.
There are several problems at hand:
1. Rails 2.3.5 declares it is only compatible with Rack 1.0.x
2. Unicorn does not require any particular Rack version
3. RubyGems defaults to the latest version of any Gem if
no version is explicitly specified.
Since Unicorn is loaded before Rails, RubyGems will default to
loading the latest version of Rack based on the Unicorn gemspec
You have several other options here to work around this,
they all suck (in no particular order of suckiness):
1. edit the installed Rails/active* gemspecs[1] so they're not
pinned on on 1.0.x anymore (they *should* be compatible enough)
1a. vendorize Rails/active* and edit the gemspecs there
2. edit your copy of /path/to/unicorn_rails and
activate Rack 1.0.x in there before Unicorn is activated
(this is the "unicorn_rails" wrapper RubyGems creates for you,
not the actual "unicorn_rails" source).
3. create a "vendored" copy of unicorn_rails for your
application (script/my_unicorn) and activate Rack 1.0.x
in there first.
4. install Unicorn using setup.rb without RubyGems
(uninstalls/upgrades won't be as nice to deal with, though).
5. edit the installed Unicorn gemspec[1] to depend on Rack ~> 1.0
[1] - RubyGems gemspecs are here:
$prefix/lib/ruby/gems/$RUBY_VERSION/specifications/*.gemspec
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 4%]
* Unicorn 0.96 doesn't play nice with Rails 2.3.5
@ 2010-01-11 22:27 4% Peter Kieltyka
2010-01-12 3:42 4% ` Eric Wong
2010-01-19 21:50 0% ` Iñaki Baz Castillo
0 siblings, 2 replies; 200+ results
From: Peter Kieltyka @ 2010-01-11 22:27 UTC (permalink / raw)
To: mongrel-unicorn
Hello,
I've experienced a bug while trying to setup Unicorn 0.96.0 with my Rails 2.3.5 app. Some details on my system: I'm running Freebsd 8.0-p2 (amd64) with Ruby 1.9.1 and Rubygems 1.3.5.
Pretty much, I tried running "unicorn_rails" in the root of my rails application, but it never loads. What happens is the master process load then it keeps trying to start the worker app but fails. I kept getting the message that I need to install Rails 2.3.5. At fist I thought I had configured something incorrectly and there was a bad reference to my gems, but no. The error message came from my Rails config/boot.rb file which is called after the gem list has been refreshed (via app.call in Unicorn). I traced through unicorn until I found that in the load_rails_gem method of the GemBoot class was raising the load error. When checking the exception message variable it told me:
$ unicorn_rails
I, [2010-01-11T16:20:11.330566 #23391] INFO -- : listening on addr=0.0.0.0:8080 fd=3
I, [2010-01-11T16:20:11.337793 #23391] INFO -- : worker=0 spawning...
I, [2010-01-11T16:20:11.339090 #23391] INFO -- : master process ready
I, [2010-01-11T16:20:11.339225 #23393] INFO -- : worker=0 spawned pid=23393
I, [2010-01-11T16:20:11.379570 #23393] INFO -- : Refreshing Gem list
Missing the Rails 2.3.5 gem. Please `gem install -v=2.3.5 rails`, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or comment out RAILS_GEM_VERSION to use the latest version installed.
I, [2010-01-11T16:20:11.446208 #23391] INFO -- : reaped #<Process::Status: pid 23393 exit 1> worker=0
I, [2010-01-11T16:20:11.446461 #23391] INFO -- : worker=0 spawning...
I, [2010-01-11T16:20:11.447539 #23394] INFO -- : worker=0 spawned pid=23394
I, [2010-01-11T16:20:11.488722 #23394] INFO -- : Refreshing Gem list
Missing the Rails 2.3.5 gem. Please `gem install -v=2.3.5 rails`, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or comment out RAILS_GEM_VERSION to use the latest version installed.
... etc. ... keeps going on and on and on.
The exception message in GemBoot tells me:
can't activate rack (~> 1.0.0, runtime) for ["actionpack-2.3.5", "rails-2.3.5"], already activated rack-1.1.0 for ["unicorn-0.96.0"]
So, I uninstalled rack 1.1.0, leaving behind just rack 1.0.1. Started up the unicorn_rails again and voila. The issue seemed to be a conflict with the rack 1.1 already being loaded by Unicorn, and when Rails begins to load and checks its dependencies, the rack version is too new for 2.3.5.
I'm not sure what the fix is here, but uninstalling rack 1.1 probably is not the answer.
Cheers,
Peter
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 4%]
* [ANN] unicorn 0.96.0 - Rack 1.1 extras for fast clients
@ 2010-01-08 6:19 3% Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2010-01-08 6:19 UTC (permalink / raw)
To: mongrel-unicorn, ruby-talk
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/
* mongrel-unicorn@rubyforge.org
* git://git.bogomips.org/unicorn.git
Changes:
This release includes small changes for things allowed by Rack
1.1. It is also now easier to detect if daemonized process
fails to start. Manpages received some minor updates as well.
Rack 1.1 allowed us to make the following environment changes:
* "rack.logger" is now set to the "logger" specified in
the Unicorn config file. This defaults to a Logger
instance pointing to $stderr.
* "rack.version" is now at [1,1]. Unicorn remains
compatible with previous Rack versions if your app
depends on it.
While only specified since Rack 1.1, Unicorn has always exposed
"rack.input" in binary mode (and has ridiculous integration
tests that go outside of Ruby to prove it!).
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
* Re: PID is not regenerated when using "-P" and the master receives USR2
2009-12-31 21:26 0% ` Iñaki Baz Castillo
@ 2009-12-31 21:41 0% ` Eric Wong
0 siblings, 0 replies; 200+ results
From: Eric Wong @ 2009-12-31 21:41 UTC (permalink / raw)
To: unicorn list
Iñaki Baz Castillo <ibc@aliax.net> wrote:
> El Jueves, 31 de Diciembre de 2009, Iñaki Baz Castillo escribió:
> > El Jueves, 31 de Diciembre de 2009, Eric Wong escribió:
> > > Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > > > El Jueves, 31 de Diciembre de 2009, Iñaki Baz Castillo escribió:
<snip>
> > > All command-line arguments are passed to the child process. We capture
> > > the command-line as soon as possible before option parsing happens.
> >
> > However I use a modified version of "unicorn" executable, which is the same
> > with just two differences:
> >
> > - The name is different.
> >
> > - The commandline "-c" and "rackup" are removed. Instead these values are
> > fixed and I set them into the executable script by adding:
> >
> > options[:config_file] = "PATH_TO_UNICORN_CONFIG.rb"
> > config = "PATH_TO_CONFIG.ru"
> >
> >
> > So to run as daemon I just type:
> >
> > ~# myapp -D -P /tmp/myapp.pid
> >
> >
> > Could it explain my issue? I see "/tmp/myapp.pid.oldbin" after USR2, but I
> > don't see a new "/tmp/myapp.pid".
> >
> >
> > Thanks a lot for your help.
>
>
> I've some issue somewhere as when sending the USR2 I see:
>
> INFO: executing ["/usr/local/bin/myapp"] (in /)
>
> while it should be ["/usr/local/bin/myapp","-P","/tmp/myapp.pid","-D"]
You need to require 'unicorn/launcher' or 'unicorn' before you do any
option parsing to stash ARGV in a safe place.
You can also play with the Unicorn::HttpServer::START_CTX hash
and modify the :argv array value if needed...
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: PID is not regenerated when using "-P" and the master receives USR2
2009-12-31 20:40 3% ` Iñaki Baz Castillo
@ 2009-12-31 21:26 0% ` Iñaki Baz Castillo
2009-12-31 21:41 0% ` Eric Wong
0 siblings, 1 reply; 200+ results
From: Iñaki Baz Castillo @ 2009-12-31 21:26 UTC (permalink / raw)
To: mongrel-unicorn
El Jueves, 31 de Diciembre de 2009, Iñaki Baz Castillo escribió:
> El Jueves, 31 de Diciembre de 2009, Eric Wong escribió:
> > Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > > El Jueves, 31 de Diciembre de 2009, Iñaki Baz Castillo escribió:
> > > > In case of using "unicorn -P PIDFILE" when the master receives a USR2
> > > > the pidfile is deleted and not regenerated anymore.
> > > >
> > > > In case of using "pid" mehotd in config file then it works well.
> > > >
> > > > It seems a bug, do I miss something?
> > >
> > > Definitively I think this is the expected behaviour as the new binary
> > > has no way to know the PIDFILE passed as commandline argument to
> > > original binary, am I right?
> >
> > All command-line arguments are passed to the child process. We capture
> > the command-line as soon as possible before option parsing happens.
> >
> > When USR2 is received, we create a new pid file for the old
> > binary and add the ".oldbin" suffix to the pathname.
> >
> > That said, "-P" in the command-line and "pid" in the config file should
> > work the same. Despite being officially deprecated, "-P" is used
> > extensively and interchangeably with "pid" in the existing tests.
>
> Yes, I confirm that using pure "unicorn" command with "-P" it works (both
> "name.pid" and "name.pid.oldbin" exist after USR2).
>
> However I use a modified version of "unicorn" executable, which is the same
> with just two differences:
>
> - The name is different.
>
> - The commandline "-c" and "rackup" are removed. Instead these values are
> fixed and I set them into the executable script by adding:
>
> options[:config_file] = "PATH_TO_UNICORN_CONFIG.rb"
> config = "PATH_TO_CONFIG.ru"
>
>
> So to run as daemon I just type:
>
> ~# myapp -D -P /tmp/myapp.pid
>
>
> Could it explain my issue? I see "/tmp/myapp.pid.oldbin" after USR2, but I
> don't see a new "/tmp/myapp.pid".
>
>
> Thanks a lot for your help.
I've some issue somewhere as when sending the USR2 I see:
INFO: executing ["/usr/local/bin/myapp"] (in /)
while it should be ["/usr/local/bin/myapp","-P","/tmp/myapp.pid","-D"]
--
Iñaki Baz Castillo <ibc@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: PID is not regenerated when using "-P" and the master receives USR2
@ 2009-12-31 20:40 3% ` Iñaki Baz Castillo
2009-12-31 21:26 0% ` Iñaki Baz Castillo
0 siblings, 1 reply; 200+ results
From: Iñaki Baz Castillo @ 2009-12-31 20:40 UTC (permalink / raw)
To: mongrel-unicorn
El Jueves, 31 de Diciembre de 2009, Eric Wong escribió:
> Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > El Jueves, 31 de Diciembre de 2009, Iñaki Baz Castillo escribió:
> > > In case of using "unicorn -P PIDFILE" when the master receives a USR2
> > > the pidfile is deleted and not regenerated anymore.
> > >
> > > In case of using "pid" mehotd in config file then it works well.
> > >
> > > It seems a bug, do I miss something?
> >
> > Definitively I think this is the expected behaviour as the new binary has
> > no way to know the PIDFILE passed as commandline argument to original
> > binary, am I right?
>
> All command-line arguments are passed to the child process. We capture
> the command-line as soon as possible before option parsing happens.
>
> When USR2 is received, we create a new pid file for the old
> binary and add the ".oldbin" suffix to the pathname.
>
> That said, "-P" in the command-line and "pid" in the config file should
> work the same. Despite being officially deprecated, "-P" is used
> extensively and interchangeably with "pid" in the existing tests.
Yes, I confirm that using pure "unicorn" command with "-P" it works (both
"name.pid" and "name.pid.oldbin" exist after USR2).
However I use a modified version of "unicorn" executable, which is the same
with just two differences:
- The name is different.
- The commandline "-c" and "rackup" are removed. Instead these values are
fixed and I set them into the executable script by adding:
options[:config_file] = "PATH_TO_UNICORN_CONFIG.rb"
config = "PATH_TO_CONFIG.ru"
So to run as daemon I just type:
~# myapp -D -P /tmp/myapp.pid
Could it explain my issue? I see "/tmp/myapp.pid.oldbin" after USR2, but I
don't see a new "/tmp/myapp.pid".
Thanks a lot for your help.
--
Iñaki Baz Castillo <ibc@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 3%]
Results 201-400 of ~500 next (older) | prev (newer) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2009-11-26 4:50 feature request - when_ready() hook Suraj Kurapati
2009-11-26 6:05 ` Eric Wong
2009-11-26 19:05 ` Suraj Kurapati
2009-11-26 19:53 ` Eric Wong
2009-11-30 23:47 ` Suraj Kurapati
2010-03-08 22:58 2% ` Suraj Kurapati
2009-12-31 18:01 PID is not regenerated when using "-P" and the master receives USR2 Iñaki Baz Castillo
2009-12-31 18:23 ` Iñaki Baz Castillo
2009-12-31 20:01 ` Eric Wong
2009-12-31 20:40 3% ` Iñaki Baz Castillo
2009-12-31 21:26 0% ` Iñaki Baz Castillo
2009-12-31 21:41 0% ` Eric Wong
2010-01-08 6:19 3% [ANN] unicorn 0.96.0 - Rack 1.1 extras for fast clients Eric Wong
2010-01-11 22:27 4% Unicorn 0.96 doesn't play nice with Rails 2.3.5 Peter Kieltyka
2010-01-12 3:42 4% ` Eric Wong
2010-01-12 14:36 0% ` Peter Kieltyka
2010-01-19 21:50 0% ` Iñaki Baz Castillo
2010-01-17 1:44 Issue when sending USR2 too soon Iñaki Baz Castillo
2010-01-17 1:59 ` Iñaki Baz Castillo
2010-01-18 11:04 ` Eric Wong
2010-01-18 11:25 3% ` Iñaki Baz Castillo
2010-01-18 11:43 0% ` Eric Wong
2010-01-19 21:42 3% Unicorn can't find gems? Steve Klabnik
2010-01-19 21:48 3% ` Eric Wong
2010-01-19 21:56 4% ` David Palm
2010-01-22 6:30 Getting a strange cookie error Travis Bell
2010-01-22 20:06 ` Travis Bell
2010-01-22 23:29 3% ` Travis Bell
2010-01-28 22:19 0% ` Eric Wong
2010-01-26 2:35 4% [PATCH] KNOWN_ISSUES: background threads + Logger monkey patch Eric Wong
2010-02-04 8:16 "upstream timed out" after upgrades John-Paul Bader
2010-02-04 8:48 1% ` John-Paul Bader
2010-02-04 9:28 ` John-Paul Bader
2010-02-04 10:11 ` Eric Wong
2010-02-04 12:26 ` John-Paul Bader
2010-02-04 14:22 ` John-Paul Bader
2010-02-04 15:11 ` John-Paul Bader
2010-02-04 19:42 ` Eric Wong
2010-02-04 20:01 ` John-Paul Bader
2010-02-04 20:14 ` Eric Wong
2010-02-04 20:23 3% ` John-Paul Bader
2010-02-18 18:01 Rails 3 "RAILS_ENV not defined by config/boot" error John Wulff
2010-02-18 19:08 ` Eric Wong
2010-02-18 23:36 7% ` Eric Wong
2010-03-16 10:09 2% Newbie problems Matt Davies
2010-03-16 18:10 0% ` Eric Wong
2010-03-18 21:12 3% Issue with unicorn not starting via bluepill? James Cox
2010-03-19 8:26 0% ` Eric Wong
2010-04-08 21:21 funky process tree + stillborn masters Jamie Wilkinson
2010-04-08 23:55 2% ` Eric Wong
2010-04-09 1:20 2% ` Eric Wong
2010-04-12 2:52 ` Eric Wong
2010-04-13 3:23 0% ` Jamie Wilkinson
2010-04-13 5:24 ` Eric Wong
2010-04-19 18:21 ` Eric Wong
2010-04-28 4:05 ` Jamie Wilkinson
2010-04-28 7:40 3% ` Eric Wong
2010-05-06 19:37 5% [ANN] unicorn 0.99.0 - simplicity wins Eric Wong
2010-05-06 20:49 0% ` Jamie Wilkinson
2010-05-06 21:01 0% ` Eric Wong
2010-05-07 13:51 Some issues in the HTTP parser (and suggestions) Iñaki Baz Castillo
2010-05-07 18:33 2% ` Eric Wong
2010-05-13 17:10 Prematurely closed connection Paul Carey
2010-05-13 20:13 3% ` Eric Wong
2010-06-02 18:01 2% Read error: #<TypeError: can't modify frozen string> raised from HttpParser Augusto Becciu
2010-06-02 20:25 0% ` Eric Wong
2010-06-02 20:47 0% ` Augusto Becciu
2010-06-02 21:38 0% ` Eric Wong
2010-06-03 23:05 0% ` Augusto Becciu
2010-06-03 23:40 0% ` Eric Wong
2010-06-08 2:02 5% ` Augusto Becciu
2010-06-08 2:45 9% ` Eric Wong
2010-06-08 3:01 0% ` Augusto Becciu
2010-06-03 17:37 Fwd: Support for Soft Timeout in Unicorn Eric Wong
2010-06-03 18:22 ` Eric Wong
2010-06-03 18:32 3% ` Pierre Baillet
2010-06-03 18:47 0% ` Eric Wong
2010-06-04 1:58 20% unicorn_rails cleanup (possible fix for Rails3) pushed Eric Wong
2010-06-08 9:51 2% [ANN] unicorn 0.990.0 - inching towards 1.0 Eric Wong
2010-06-08 12:24 unicorn_rails cleanup (possible fix for Rails3) pushed Hongli Lai
2010-06-08 19:20 7% ` Eric Wong
2010-06-08 19:25 0% ` Hongli Lai
2010-06-09 12:58 Working directory and config.ru Pierre Baillet
2010-06-09 18:04 ` Eric Wong
2010-06-10 9:58 5% ` Eric Wong
2010-06-14 19:46 Unicorn future plans Eric Wong
2010-06-14 20:58 2% ` John-Paul Bader
2010-06-14 22:10 0% ` Eric Wong
2010-06-25 15:06 2% test failure on Mac OSX Andrew Milkowski
2010-07-13 4:25 SIGWINCH Lawrence Pit
2010-07-13 8:24 3% ` SIGWINCH Eric Wong
2010-07-13 20:19 [ANN] unicorn 1.0.1 and 1.1.2 - fix rollbacks Eric Wong
2010-07-14 0:13 ` Lawrence Pit
2010-07-14 0:38 3% ` Eric Wong
2010-07-14 2:14 5% ` Lawrence Pit
2010-07-14 2:34 0% ` Eric Wong
2010-07-14 7:00 0% ` Lawrence Pit
2010-07-15 18:07 ` Jamie Wilkinson
2010-07-16 0:47 4% ` Lawrence Pit
2010-07-15 20:46 4% Problem with x-www-form-urlencoded Richard Penwell
2010-07-15 22:14 3% ` Eric Wong
2010-07-15 22:30 0% ` Richard Penwell
2010-07-15 22:40 3% ` Eric Wong
2010-07-15 23:49 0% ` Richard Penwell
2010-07-16 7:54 0% ` Eric Wong
2010-07-16 13:17 0% ` Richard Penwell
2010-08-17 1:29 running unicorn under rvm Joseph McDonald
2010-08-17 3:52 ` Eric Wong
2010-08-17 22:37 3% ` Joseph McDonald
2010-08-18 1:08 0% ` Eric Wong
2010-08-17 23:38 javascript disappears Jimmy Soho
2010-08-18 1:14 ` Eric Wong
2010-08-18 2:23 3% ` Jimmy Soho
2010-08-18 2:45 0% ` Eric Wong
[not found] <mailman.96.1282670516.23553.mongrel-unicorn@rubyforge.org>
[not found] ` <AANLkTingOCVVTyCDbA8RC=Vf7LV=HyCMhtqcJ4RLg9Xy@mail.gmail.com>
2010-08-24 19:58 ` Unicorn and home_run Eric Wong
2010-08-24 21:38 ` Jeremy Evans
2010-08-25 7:50 ` Eric Wong
2010-08-25 14:46 3% ` Jeremy Evans
2010-08-26 4:33 3% ` Eric Wong
2010-09-07 19:29 3% unicorn_rails and rails 2.3.8 Matt Smith
2010-09-11 15:42 3% ` Edho P Arief
2010-09-09 23:28 5% Unicorn fails to restart gracefully on capistrano deploy Eirik Dentz Sinclair
2010-10-14 4:58 2% completely stumped by problem encountered replacing running unicorn Justin Giancola
2010-10-14 5:50 0% ` Lawrence Pit
2010-10-14 23:01 0% ` Justin Giancola
2010-10-22 19:50 502 bad gateway on nginx with recv() failed Naresh V
2010-10-22 21:14 3% ` Eric Wong
2010-10-23 4:48 2% ` Naresh V
2010-10-28 0:19 2% [ANN] Unicorn 2.0.0, 1.1.5, 1.0.2 released! Eric Wong
2010-10-29 11:16 stop/start workers "by need" Anton A. Vesnin
2010-10-29 17:40 4% ` Eric Wong
2010-11-12 20:51 error when HUP'ing unicorn Grant Heffernan
2010-11-12 22:56 3% ` Eric Wong
2010-11-18 9:21 3% Errors in unicorn 2.0.0 and 2.0.1 gut
2010-11-18 9:51 0% ` Eric Wong
2010-11-23 23:36 10% rack 1.2 version causing misleading error msg Don Park
2011-02-28 20:51 9% ` Eric Wong
2011-01-24 1:09 Unicorn renaming unicorn.pid.oldbin back to unicorn.pid (or, is unicorn afraid to die?) Sean Grove
2011-01-24 19:09 3% ` Eric Wong
2011-01-28 9:57 Kernel.srand after_fork ghazel
2011-01-28 10:26 3% ` Eric Wong
2011-01-28 10:57 0% ` ghazel
2011-02-16 13:06 2% Forking for background processing with rails/unicorn Brian Underwood
2011-02-16 17:41 0% ` Eric Wong
2011-02-25 17:59 5% [PATCH] tee_input: remove old *BSD stdio workaround Eric Wong
2011-03-08 4:40 5% [RFC/PATCH] Bundler/Sandbox documentation updates Eric Wong
2011-03-08 14:22 0% ` Justin Giancola
2011-03-09 10:39 0% ` Lawrence Pit
2011-03-10 0:52 3% ` Eric Wong
2011-03-10 3:30 3% ` Lawrence Pit
2011-03-10 21:29 0% ` Eric Wong
2011-04-07 21:11 2% Unicorn error Ernesto Rocha
2011-04-07 22:04 0% ` Clifton King
2011-04-25 16:37 Unicorn / Daemontools Curtis j Schofield
2011-04-25 18:34 3% ` Eric Wong
2011-04-25 19:03 0% ` Curtis j Schofield
2011-04-28 0:57 adding GPLv3 to unicorn license Eric Wong
2011-04-28 0:59 7% ` [RFC/PATCH] LICENSE: add GPLv3 to license terms Eric Wong
2011-05-21 3:05 leading/trailing linear whitespace in headers Eric Wong
2011-05-21 5:14 ` Lawrence Pit
2011-05-21 5:57 3% ` Eric Wong
2011-05-27 7:32 0% ` Lawrence Pit
2011-05-30 7:02 0% ` Lawrence Pit
2011-05-23 18:37 5% [PATCH] doc: add Links page to help folks find relevant info Eric Wong
[not found] <BANLkTikFid3n0QpsrnXf2oNansFmuJDyuw@mail.gmail.com>
[not found] ` <BANLkTimF78PW9YgEAURS604Q8mucNwSDrg@mail.gmail.com>
2011-05-31 12:02 ` unicorn stuck in sched_yield after ERESTARTNOHAND Bharanee Rathna
2011-05-31 15:17 3% ` Eric Wong
2011-05-31 22:28 0% ` Bharanee Rathna
2011-06-06 17:31 [PATCH] Ensure that 'make gem' builds the documentation too Hongli Lai
2011-06-06 17:51 15% ` Eric Wong
2011-06-16 23:25 [PATCH] replace fchmod()-based heartbeat with raindrops Eric Wong
2011-06-24 17:30 ` Eric Wong
2011-06-24 18:17 ` Jeremy Evans
2011-06-24 20:51 ` Eric Wong
2011-06-24 22:50 3% ` Aleksandar Simic
2011-06-25 0:15 0% ` Eric Wong
2011-06-26 5:36 0% ` Aleksandar Simic
2011-06-20 23:40 problem setting multiple cookies Jason Su
2011-06-21 0:06 ` Eric Wong
2011-06-21 0:25 ` Jason Su
2011-06-21 0:46 ` Eric Wong
2011-06-21 1:34 ` Jason Su
2011-06-21 2:15 ` Eric Wong
2011-06-21 2:48 ` Jason Su
2011-06-21 3:15 3% ` Eric Wong
2011-06-21 3:38 0% ` Jason Su
2011-06-21 18:29 3% ` Eric Wong
2011-07-06 10:21 Unicorn completely ignores USR2 signal Ehud Rosenberg
2011-07-06 17:42 ` Eric Wong
2011-07-07 14:18 ` Eric Wong
2011-07-07 17:52 4% ` Alex Sharp
2011-07-08 18:30 2% SQL Server errors when using unicorn Marc Sernatinger
[not found] <9E260BC166D04FF1B0B7CBC563B221BA@gmail.com>
2011-06-30 3:33 ` "NoMethodError: undefined method" after switching to unicorn Tiago Scolari
2011-06-30 5:04 ` Eric Wong
2011-06-30 19:45 ` Eric Wong
2011-07-18 13:34 ` Undefined method " Douglas André
2011-07-18 19:42 5% ` Eric Wong
2011-07-23 20:18 Problems running unicorn_rails without bundle exec (in a RVM context) Maurizio De Santis
2011-07-23 20:57 3% ` Eric Wong
2011-07-23 23:03 0% ` Maurizio De Santis
2011-07-24 0:48 0% ` Scott Windsor
2011-07-25 20:21 SIGTERM not actually killing processes Jesse Cooke
2011-07-25 21:22 ` Eric Wong
[not found] ` <DA420539FB904E888DB3B397DC431B7C@gmail.com>
[not found] ` <CAFgS5CxwCmHL65W39R2W73YfUK34WX50DS_JJF4L-d_tQuH86Q@mail.gmail.com>
2011-07-25 23:20 0% ` Jesse Cooke
2011-08-02 20:09 Strange quit behavior James Cox
2011-08-02 20:34 ` Alex Sharp
2011-08-02 21:54 ` Eric Wong
2011-08-05 4:09 ` Alex Sharp
2011-08-05 4:12 ` Alex Sharp
2011-08-05 8:07 3% ` Eric Wong
2011-08-17 4:26 3% ` Alex Sharp
2011-08-17 9:22 ` Eric Wong
2011-08-17 20:13 ` Eric Wong
2011-08-18 23:13 2% ` Alex Sharp
2011-08-19 1:53 0% ` Eric Wong
2011-08-02 21:53 3% ` Eric Wong
2011-08-02 22:46 0% ` James Cox
2011-09-08 9:04 2% Sending ABRT to timeout-errant process before KILL J. Austin Hughey
2011-11-14 19:33 Fix hang when running tests on OpenBSD by skipping two tests Jeremy Evans
2011-11-14 20:54 ` Eric Wong
2011-11-14 23:46 2% ` Jeremy Evans
2011-11-15 3:17 3% ` Eric Wong
2011-11-21 23:14 Should USR2 always work? Laurens Pit
2011-11-22 1:16 ` Eric Wong
2011-11-22 1:55 3% ` Lawrence Pit
2011-11-22 3:00 0% ` Eric Wong
2011-11-23 5:31 4% ` Lawrence Pit
2012-01-08 4:00 6% oldest version of Ruby worth supporting? Eric Wong
2012-01-08 4:02 6% ` Eric Wong
2012-01-31 17:22 4% FreeBSD jail and unicorn Philipp Bruell
2012-01-31 18:39 Eric Wong
2012-01-31 18:50 ` Charles Hornberger
2012-01-31 19:05 3% ` Eric Wong
[not found] ` <CB4EBD2A.7DF%philipp.bruell@skrill.com>
2012-02-01 18:14 3% ` Eric Wong
[not found] ` <CB5014D7.892%philipp.bruell@skrill.com>
2012-02-02 19:31 0% ` Eric Wong
2012-02-07 5:21 Eric Wong
2012-02-07 7:36 3% ` Philipp Bruell
2012-02-24 17:43 using unicorn as a local development server Matt Smith
2012-02-24 23:10 3% ` Eric Wong
2012-03-01 23:52 murdering high-memory workers and auto-scaling Ben Somers
2012-03-02 1:07 2% ` Eric Wong
2012-03-09 21:48 3% Unicorn_rails ignores USR2 signal Yeung, Jeffrey
2012-03-09 22:24 0% ` Eric Wong
2012-03-09 22:39 0% ` Yeung, Jeffrey
2012-03-10 0:02 ` Eric Wong
2012-03-10 1:07 ` Yeung, Jeffrey
2012-03-10 1:30 ` Eric Wong
2012-03-12 21:21 ` Eric Wong
2012-03-12 22:39 ` Yeung, Jeffrey
2012-03-12 22:44 ` Eric Wong
2012-03-20 19:57 ` Eric Wong
2012-03-30 22:16 ` Yeung, Jeffrey
2012-03-30 22:51 3% ` Alex Sharp
2012-04-27 14:36 app error: Socket is not connected (Errno::ENOTCONN) Joel Nimety
2012-04-27 18:59 ` Eric Wong
2012-04-27 19:12 ` Joel Nimety
2012-04-27 19:32 3% ` Eric Wong
2012-04-27 19:45 4% ` Matt Smith
2012-04-27 19:47 0% ` Joel Nimety
[not found] ` <CACsAZRR=NP4O+EB0koAr0aeUwth=M+5aQnA8vtVLEXqFHd=jnA@mail.gmail.com>
2012-04-27 19:51 3% ` Eric Wong
2012-04-27 19:53 0% ` Eric Wong
2012-04-27 20:30 0% ` Matt Smith
2012-04-28 21:33 3% Socket errors and nginx 502 gateway errors Pico Aeterna
2012-04-28 21:59 ` Eric Wong
2012-04-29 16:34 1% ` Pico Aeterna
2012-04-29 19:18 0% ` Eric Wong
2012-05-02 16:30 0% ` Pico Aeterna
2012-05-09 6:18 3% unicorn 4 does not compile on Joyent (SmartOS/Solaris) due to raindrops dependency Konstantin Gredeskoul
2012-05-09 7:02 0% ` Eric Wong
2012-05-09 7:11 0% ` Konstantin Gredeskoul
2012-06-15 18:09 2% Sinatra app fails to perform at scale Eliot Shepard
2012-06-15 21:22 0% ` Eric Wong
2012-06-23 16:12 `kill -SIGTRAP <worker pid>` to get a live ruby backtrace + generate backtrace when murdering worker due to timeout Cedric Maion
2012-06-23 16:12 ` [PATCH] `kill -SIGTRAP <worker pid>` to get a live ruby backtrace + generate backtrace when murdered " Cedric Maion
2012-06-23 18:55 ` [PATCH] `kill -SIGTRAP <worker pid>` Eric Wong
2012-06-24 11:05 3% ` Cedric Maion
2012-06-27 16:08 Unicorn workers under Monit Manuel Palenciano Guerrero
2012-06-27 18:35 3% ` Eric Wong
2012-07-17 0:33 3% Any signal other than -9 causes full CPU utilization by master unicorn process on FreeBSD Mark Mccraw
2012-07-19 22:43 Detecting unicorn / defining after_fork after master startup Matt Sanders
2012-07-19 23:13 ` Eric Wong
2012-07-21 19:42 ` Matt Sanders
2012-07-22 21:20 3% ` Eric Wong
2012-07-28 2:22 6% [RFC/PATCH] remove Rails-oriented integration tests Eric Wong
2012-08-07 7:26 SIGUSR2 from symlinked working directory Danial Pearce
[not found] ` <CAOX4-H6ZgeiFmJXnV7AENBMEuLCkMYCMiabmxh_L8vE6yuxaBQ@mail.gmail.com>
2012-08-07 8:19 ` Danial Pearce
[not found] ` <7FF46C3E-8491-43D8-8617-9D628C4A85C7@gmail.com>
2012-08-07 8:58 3% ` Danial Pearce
2012-10-02 0:59 [PATCH] chowning /dev/null should be guarded against Joel Meador
2012-10-02 1:27 ` Eric Wong
2012-10-02 1:48 ` Joel Meador
2012-10-02 4:25 3% ` Eric Wong
2012-10-12 17:55 [PATCH] explicitly use escaped minus in man pages Hleb Valoshka
2012-10-15 18:50 ` Eric Wong
2012-10-17 15:33 ` Hleb Valoshka
2012-10-18 8:04 3% ` Eric Wong
2012-10-29 17:44 Combating nginx 499 HTTP responses during flash traffic scenario Tom Burns
2012-10-29 18:45 ` Eric Wong
2012-10-29 21:53 ` Eric Wong
2012-10-30 20:40 ` Tom Burns
2012-10-30 21:37 ` Eric Wong
2012-11-02 17:59 2% ` Tom Burns
2012-11-02 19:38 ` Eric Wong
2012-11-03 22:45 2% ` Tom Burns
2012-11-05 11:48 ` Eric Wong
2012-11-06 3:16 2% ` Tom Burns
2012-11-06 21:23 0% ` Eric Wong
2012-11-29 15:52 3% ` Tom Burns
2012-11-29 20:41 0% ` Eric Wong
2012-11-28 13:32 When a client terminates a connection Andrew Stewart
2012-11-29 17:09 ` Iñaki Baz Castillo
2012-11-29 23:04 ` Eric Wong
2012-11-30 9:15 ` Andrew Stewart
2012-11-30 19:26 ` Eric Wong
2012-12-03 14:42 3% ` Andrew Stewart
[not found] <CA+c-+BYTxv+5mQ2MKeKVYEoxgPbi2QjwY6Oak-R_g65GhixEzg@mail.gmail.com>
2012-12-05 5:19 2% ` Fwd: Issue starting unicorn with non-ActiveRecord Rails app Peter Hall
2012-12-05 7:45 3% ` Eric Wong
2012-12-05 7:48 0% ` Daniel Condomitti
2012-12-06 19:48 Unicorn fails to install even though it's already installed and running Mac Martine
2012-12-06 20:23 ` Eric Wong
2012-12-06 21:11 ` Mac Martine
2012-12-06 21:54 3% ` Eric Wong
2013-01-20 7:36 preload_app = true causing - ActiveModel::MissingAttributeError: missing attribute: some_attr Avner Cohen
2013-01-20 8:04 ` Eric Wong
2013-01-20 8:10 ` Avner Cohen
2013-01-20 9:17 ` Eric Wong
2013-01-21 7:55 ` Avner Cohen
2013-01-21 8:11 3% ` Lawrence Pit
[not found] <CAKjxZvr-LJuY4LP4ZQa4yCs40SB8i2Y7N-hrgPxDxLc4uSM9Mg@mail.gmail.com>
2013-01-21 10:28 3% ` your mail Eric Wong
2013-01-22 11:49 10% [PATCH] support for Rack hijack in request and response Eric Wong
2013-01-24 8:42 0% SIGSEGV at shutdown (was: Re: your mail) Charles Hornberger
2013-01-24 9:52 0% ` Eric Wong
2013-01-24 10:27 0% ` Charles Hornberger
2013-01-29 21:10 20% [ANN] unicorn 4.6.0pre1 - hijacking support! Eric Wong
2013-02-08 13:54 6% Unicorn 4.6.0 version is 4.5.0 Maurizio De Santis
2013-02-08 18:55 35% ` [PATCH] auto-generate Unicorn::Const::UNICORN_VERSION Eric Wong
2013-02-09 1:16 3% What's cooking in unicorn.git Eric Wong
2013-02-09 1:16 15% ` [PATCH 1/2] http_request: remove FIXME for rack.version clarification Eric Wong
2013-02-14 14:10 11% Changing Ruby version Jérémy Lecour
2013-02-14 20:20 9% ` Eric Wong
2013-02-14 21:35 6% ` Jérémy Lecour
2013-02-21 8:50 3% [ANN] unicorn 4.6.1 - minor cleanups Eric Wong
2013-04-20 0:52 Worker Timeout Debugging Bill Vieux
2013-04-20 1:26 4% ` Eric Wong
2013-05-10 13:00 2% Unicorn behaving irrationally in production after a day Bogdan Dumitru
2013-05-10 14:33 0% ` Aaron Suggs
Code repositories for project(s) associated with this public inbox
https://yhbt.net/unicorn.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).