Eric Wong | 17 Nov 23:06 2015

[PATCH] add .gitattributes for Ruby method detection

The "diff" function detection for C does not map well to
Ruby files, take advantage of gitattributes(5) to improve
method name detection in generated patches as well as
making "git diff -W" output more useful.
 .gitattributes | 5 +++++
 1 file changed, 5 insertions(+)
 create mode 100644 .gitattributes

diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000..21e0bd4
--- /dev/null
+++ b/.gitattributes
 <at>  <at>  -0,0 +1,5  <at>  <at> 
+*.gemspec diff=ruby
+*.rb diff=ruby
+*.ru diff=ruby
+Rakefile diff=ruby
+bin/* diff=ruby


unsubscribe: unicorn-public+unsubscribe <at>

Eric Wong | 17 Nov 22:45 2015

[PATCH] examples: add systemd socket and service files

Since we have init scripts, we ought to have the equivalent for
systemd users who cannot upgrade via the normal SIGUSR2 mechanism;
but can use multiple services: "unicorn <at> 1" + h"unicorn <at> 2" to
accomplish the same thing.

Based on examples by Christos Trochalakis <yatiohi <at>>

ref: <at>
 examples/unicorn.socket   | 11 +++++++++++
 examples/unicorn <at> .service | 26 ++++++++++++++++++++++++++
 2 files changed, 37 insertions(+)
 create mode 100644 examples/unicorn.socket
 create mode 100644 examples/unicorn <at> .service

diff --git a/examples/unicorn.socket b/examples/unicorn.socket
new file mode 100644
index 0000000..7d5f773
--- /dev/null
+++ b/examples/unicorn.socket
 <at>  <at>  -0,0 +1,11  <at>  <at> 
+# ==> /etc/systemd/system/unicorn.socket <==
+Description = unicorn sockets
+ListenStream =
+ListenStream = /tmp/path/to/.unicorn.sock
+Service = unicorn <at> 1.service
(Continue reading)

Owen Ou | 17 Nov 00:43 2015

undefined method `include?' for nil:NilClass (NoMethodError)


We recently upgraded to Unicorn 5.0 but getting the following error:

[2015-11-16T14:54:16.943652 #19838] ERROR -- : app error: undefined
method `include?' for nil:NilClass (NoMethodError)

E, [2015-11-16T14:54:16.943712 #19838] ERROR -- :
`block in http_response_write'

E, [2015-11-16T14:54:16.943737 #19838] ERROR -- :
`block in each'

E, [2015-11-16T14:54:16.943753 #19838] ERROR -- :

E, [2015-11-16T14:54:16.943767 #19838] ERROR -- :

The error came from this commit:
And specifically the line of `if value =~ /\n/` is changed to `if
value.include?("\n".freeze)`. Apparently `value` can be nil which
caused our issue. It should be an easy fix.

(Continue reading)

Jeff Utter | 13 Nov 01:51 2015

Shared Metrics Between Workers


I was wondering if anyone can offer any advice in handling stats
collections between worker processes in forking servers (like unicorn).
Specifically, I am attempting to work on a solution for the Prometheus ruby
gem. Some details are in this issue here:

Prometheus works with a "scrape" model, where every few seconds a
prometheus server hits a http endpoint that exposes status. With the
current middleware the stats will only represent whichever worker is hit.

I have read through the documentation for unicorn and poked around the
source code some  -- as well as searched for similar projects for

The earliest, promising solution I considered was raindrops, but it looks
as though you need to know all of the possible metrics up front - which
won't necessarily work as prometheus could use metrics based on parameters
which could vary.

Does anyone have any experience working with something like this?

Thanks for any suggestions.

Eric Wong | 1 Nov 09:37 2015

[PATCH 0/3] last updates before 5.0 release

Nothing significant...

Eric Wong (3):
      golf down conditional for socket activation
      gemspec: relax Ruby version requirement for old RubyGems
      doc updates

 ISSUES                     |  2 +-
 Links                      |  7 ++++---
 lib/unicorn/http_server.rb |  2 +-
 unicorn.gemspec            | 12 ++++++++++--
 4 files changed, 16 insertions(+), 7 deletions(-)

unsubscribe: unicorn-public+unsubscribe <at>

Eric Wong | 27 Oct 04:33 2015

[PATCH 0/2] socket inheritance behavior/bug => feature!

Given long enough, some bugs need to become documented behavior
(see [PATCH 2/2]).

Anyways, I guess we'll release 5.0.0 final in a day or two.  I was
intending to release 5.0.0 today until I noticed how un-DRY having
listeners configured in both systemd and unicorn config files would
be.  And then I noticed we have an existing bug as documented in 2/2
which would allow the user to be DRY after all.

Eric Wong (2):
      sd_listen_fds emulation cleanup
      inheriting sockets from UNICORN_FD does not close them

 Documentation/unicorn.1.txt |  4 +---
 lib/unicorn/http_server.rb  |  4 ++--
 test/exec/test_exec.rb      | 50 ++++++++++++++++++++++++++++++++++-----------
 3 files changed, 41 insertions(+), 17 deletions(-)

Fwiw, in case anybody is uncomfortable with the mere mention of the
word "systemd"; unicorn will never have any dependencies on systemd.
It will merely use systemd if available.
unsubscribe: unicorn-public+unsubscribe <at>

Eric Wong | 15 Oct 19:46 2015

[PATCH] unicorn.conf.rb: remove mention of REE-specific setting

Ruby 2.0+ has a copy-on-write-friendly memory layout by default,
and REE is long dead and just confusing to new users.
 examples/unicorn.conf.rb | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/examples/unicorn.conf.rb b/examples/unicorn.conf.rb
index 4b28a5a..1e05cbb 100644
--- a/examples/unicorn.conf.rb
+++ b/examples/unicorn.conf.rb
 <at>  <at>  -40,11 +40,8  <at>  <at>  pid "/path/to/app/shared/pids/"
 stderr_path "/path/to/app/shared/log/unicorn.stderr.log"
 stdout_path "/path/to/app/shared/log/unicorn.stdout.log"

-# combine Ruby 2.0.0dev or REE with "preload_app true" for memory savings
+# combine Ruby 2.0.0+ with "preload_app true" for memory savings
 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


unsubscribe: unicorn-public+unsubscribe <at>

(Continue reading)

Eric Wong | 14 Oct 22:12 2015

unicorn non-technical FAQ

Maybe this should be on the website somewhere, but the mailing list
archives are quite accessible nowadays.

Fwiw, I tend to followup publically (anonymized content) with technical
stuff to the private email address <unicorn <at>>, but never
publically address the non-technical questions.  But some of the same
questions come up over and over, so I figure an FAQ might help.

Q: Can I use your logo?

A: What logo?  This project has never had a logo and never will.
   Logos are a waste of bandwidth, processing power, and
   yet-another potential exploitable code execution and/or
   denial-of-service vector.

   Ask the webmaster of the site you saw the logo on.

Q: Can you speak at so-and-so conference?

A: I do not speak.  Speech is synchronous and I will inevitably
   speak too fast for some, too slow for others; all while wasting
   CPU power and bandwidth to encode and distribute audio.

   Text is much more efficient as the reader can read at their
   own pace, skim over uninteresting parts, scan, etc.
   Text is far cheaper to distribute, archive and search than audio.

   Besides, unicorn has been technically obsolete since the early 90s,
   there's nothing interesting to talk about.  Read the source,
   mailing list archives, git commit history, etc. instead.
(Continue reading)

Eric Wong | 5 Oct 04:43 2015

[PATCH] doc: update mail archive info

public-inbox supports read-only NNTP access nowadays to make it
easier to follow archives.  It is read-only to encourage Cc:-ing
all participants (which avoids reliance on the few-points-of-failure
behavior of NNTP).  Unlike email, NNTP also lacks good anti-spam

Additionally, the gmane group also got redirected to the address at some point since RubyForge died.

While we're at it, link to my post about enabling the submission
port (587).  It's been a year and nothing bad has happened, yet.

Finally, remove most of the documentation for ssoma since it's
unlikely anybody will use it given the existence of NNTP access.
It did little besides clutter the page.  However, git:// (used
by ssoma) remains strictly more efficient than NNTP.

Vebavpnyyl, gur AAGC freire sbe choyvp-vaobk pna unaqyr
gubhfnaqf bs fybj pyvragf.  Fbzrguvat havpbea jvyy arire or noyr
gb qb :C
 ISSUES | 45 ++++++++++++++++++---------------------------
 README |  5 +++++
 2 files changed, 23 insertions(+), 27 deletions(-)

diff --git a/ISSUES b/ISSUES
index b172f8a..7c91555 100644
--- a/ISSUES
+++ b/ISSUES
 <at>  <at>  -11,6 +11,8  <at>  <at>  submit patches and/or obtain support after you have searched the
(Continue reading)

Pirate Praveen | 29 Sep 08:38 2015

Request to follow SemVer/mention it in homepage


Do you follow Semantic Versioning as defined by If yes,
can you mention it on the homepage? If not, can you consider it?

It will help us a lot in maintain rails applications in debian. We
like to keep only one version of any app/lib in debian and if you can
guarantee Semantic Versioning rails apps using unicorn could declare a
looser dependency rather than upto the patch version. Now gitlab
defines unicorn ~> 4.8.3 and diaspora defines ~> 4.9.0 If you are
following Semantic Versioning they could change it to ~> 4.8 and ~>
4.9 and 4.9.0 will satisfy both. Currently debian has 4.9.0 and it
does not match ~> 4.8.3

Bráulio Bhavamitra | 13 Sep 17:12 2015

Re: Request Queueing after deploy + USR2 restart

Sakis, ressurecting this.

I'm seeing this after the upgrade from rails 3.2 to rails 4.2. Maybe it is
because of adequate record and other "cached on first time used" stuff.


> On Tue, Mar 3, 2015 at 7:26 PM Sarkis Varozian <svarozian <at>> wrote:
>> We have a rails application with the following unicorn.rb:
>> When we deploy to the application, a USR2 signal is sent to the unicorn
>> master which spins up a new master and we use the before_fork in the
>> unicorn.rb config above to send signals to the old master as the new
>> workers come online.
>> I've been trying to debug a weird issue that manifests as "Request
>> Queueing" in our Newrelic APM. The graph shows what happens after a
>> deployment (represented by the vertical lines). Here is the graph:
>> . As you see from the graph, it is inconsistent -
>> there is always a latency spike - however, at times Request Queueing is
>> higher than previous deploys.
>> Any ideas on what exactly is going on here? Any suggestions on
>> tools/profilers to use to get to the bottom of this? Should we expect this
>> to happen on each deploy?
>> Thanks,
(Continue reading)