Adam Fields | 15 Apr 05:26 2016

Dead PostgreSQL connections on worker restart

We have discovered that every time a unicorn worker is restarted, rails throws "PG::ConnectionBad:
connection is closed” errors.

We are using preload: true, and have before and after fork rules to close and reopen the connections:

before_fork do |server, worker|
 defined?(ActiveRecord::Base) and

   old_pid = "#{server.config[:pid]}.oldbin"
   if File.exist?(old_pid) && != old_pid
       sig = ( + 1) >= server.worker_processes ? :QUIT : :TTOU
     rescue Errno::ENOENT, Errno::ESRCH
       # someone else did our job for us

after_fork do |_server, _worker|
  defined?(ActiveRecord::Base) and ActiveRecord::Base.establish_connection

  child_pid = _server.config[:pid].sub('.pid', ".#{}.pid")
  system("echo #{} > #{child_pid}")

Yet it seems that something is holding onto a dead connection and trying to use it. 
(Continue reading)

Eric Wong | 31 Mar 03:41 2016

[PATCH] doc: further trimming to reduce noise

It's not worth mentioning pre-Rack versions of Rails anymore,
and there are a few async Rack applications reliant on
EventMachine which we do not use.

Some uses of chunked request decoding are not well-handled
with nginx in front, anyways; so avoid mentioning them.

Additionally, avoid introducing new terms into the lexicon
and just refer to "mailing list" as a generic term.
 ISSUES | 8 +++-----
 README | 7 +------
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/ISSUES b/ISSUES
index 394c852..21bd013 100644
--- a/ISSUES
+++ b/ISSUES
 <at>  <at>  -5,7 +5,7  <at>  <at>  submit patches and/or obtain support after you have searched the
 {email archives}[] and

-* No subscription will ever be required to email the public inbox.
+* No subscription will ever be required to email us
 * Cc: all participants in a thread or commit, as subscription is optional
 * Do not {top post}[] in replies
 * Quote as little as possible of the message you're replying to
 <at>  <at>  -69,9 +69,7  <at>  <at>  document distributed with git) on guidelines for patch submission.
 * nntp://
(Continue reading)

Hleb Valoshka | 17 Mar 15:46 2016

ip addresses in log files

Hello all!

Simple question I hope.

What is the simplest way to change log file format, without monkey
patching Rack::CommonLogger?

I don't want to see all addresses from X-Forwarded-For.


Shota Fukumori (sora_h | 15 Mar 08:36 2016
Gravatar accepts client certificate?


I found that accepts client certificate.
My browser prompts what certificate to use for a connection, even doesn't require a client certificate.

I and my colleagues are surprised about browser asking it. I guess
this is unexpected behavior, is it expected?

Amir Yalon | 8 Mar 00:08 2016

Systemd socket inheritance fails with “not a socket file descriptor”

I have yet to compile a minimal failing configuration, but posting here
in case it’s a common problem.
Starting the systemd service with a configuration based on <at>
(also found under examples/ in the source code), it fails, and the
following is seen in the systemd journal:
> app/vendor/bundle/ruby/2.0.0/gems/unicorn-5.0.1/lib/unicorn/http_server.rb:780:in
`for_fd': not a socket file descriptor (ArgumentError)
> from app/vendor/bundle/ruby/2.0.0/gems/unicorn-5.0.1/lib/unicorn/http_server.rb:780:in
`block in inherit_listeners!'
> from app/vendor/bundle/ruby/2.0.0/gems/unicorn-5.0.1/lib/unicorn/http_server.rb:779:in `map!'
> from app/vendor/bundle/ruby/2.0.0/gems/unicorn-5.0.1/lib/unicorn/http_server.rb:779:in `inherit_listeners!'
> from app/vendor/bundle/ruby/2.0.0/gems/unicorn-5.0.1/lib/unicorn/http_server.rb:111:in `start'
> from app/vendor/bundle/ruby/2.0.0/gems/unicorn-5.0.1/bin/unicorn:126:in `<top (required)>'
> from app/vendor/bundle/ruby/2.0.0/bin/unicorn:23:in `load'
> from app/vendor/bundle/ruby/2.0.0/bin/unicorn:23:in `<main>'
The error, in `for_fd': not a socket file descriptor (ArgumentError),
occurs when attempting `io = Socket.for_fd(fd.to_i)`.
Using Ruby version 2.0.0p645.  Should I try using 2.2 or later?

(Continue reading)

Eric Wong | 6 Mar 03:21 2016

nginx-like reverse proxies as a "sponge"?

Lately, I've caught myself refering to reverse proxies like
nginx as a "sponge" to soak up requests/responses in between
the app server and slow clients.

Perhaps it's easier to use the term "sponge" drive home the point
that unicorn should never be exposed to slow clients?

Anyways it's still disappointing that people still use unicorn
with no proxy at all or proxies that can't completely buffer

And perhaps nginx needs some competition as a sponge for unicorn: <at>
unsubscribe: unicorn-public+unsubscribe <at>

Eric Wong | 30 Jan 10:34 2016

Re: unicorn log attack?

Lawrence Pit <lawrencepit <at>> wrote:
> Hi Eric,
> I'm writing to you directly instead of to the unicorn-public list.

Which got your HTML email tarpitted in my spam folder instead of
being bounced back right away so you could fix it :)

> I noticed yesterday our unicorn.log files, which are usually tiny,
> were gigantic in size. Fortunately, this was caused by a friendly
> attack, but had they persisted I think we would've run out of
> diskspace (of which we would've been warned in advance, so we
> could've dealt with the situation I suppose had it happened)
> Upon inspection it seems requests were received as shown below (
> I've cut out the middle part of the value that was part of the form
> body that was posted )
> The log statement is printed out by unicorn.rb method +log_error+.
> I'm not sure this is a unicorn issue, and thinking more an issue of
> how we developers should deal with repeatedly receiving the same
> sort of (sometimes very large) exceptions? Any advice?

Right, not a unicorn issue :)

Use logrotate or similar, compress your logs frequently, be
mindful of what you dump from your app; and watch your disk
usage (which you seem to be doing already), but that includes
emails :)
(Continue reading)

Eric Wong | 28 Jan 00:16 2016

[ANN] unicorn 5.1.0.pre1 - Rack HTTP server for fast clients and *nix

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.

* public list: unicorn-public <at>
* mail archives:
* git clone git://
* nntp://

This is a pre-release, you will need to specify the version to
install explicitly when using RubyGems.


    unicorn 5.1.0.pre1 - rack is optional, again

    The big change is rack is not required (but still recommended).
    Applications are expected to depend on rack on their own so they can
    specify the version of rack they prefer without unicorn pulling
    in a newer, potentially incompatible version.

    unicorn will always attempt to work with multiple versions of rack
    as practical.

    The HTTP parser also switched to using the TypedData C-API for
    extra type safety and memory usage accounting support in the
(Continue reading)

Eric Wong | 27 Jan 23:55 2016

[PATCH] doc update for ClientShutdown exceptions class

State explicitly applications should not rely on it, and instead
rescue the generic EOFError exception.  This class will stick
around because there may inevitably be things which rely on it,
but we should not encourage it, either.
 lib/unicorn.rb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/unicorn.rb b/lib/unicorn.rb
index bb66b61..f122563 100644
--- a/lib/unicorn.rb
+++ b/lib/unicorn.rb
 <at>  <at>  -25,7 +25,9  <at>  <at>  module Unicorn
   # application dispatch.  This is always raised with an empty backtrace
   # since there is nothing in the application stack that is responsible
   # for client shutdowns/disconnects.  This exception is visible to Rack
-  # applications unless PrereadInput middleware is loaded.
+  # applications unless PrereadInput middleware is loaded.  This
+  # is a subclass of the standard EOFError class and applications should
+  # not rescue it explicitly, but rescue EOFError instead.
   ClientShutdown =

   # :stopdoc:


unsubscribe: unicorn-public+unsubscribe <at>

(Continue reading)

Francesco Savignago | 13 Jan 10:06 2016

behaviour with signal HUP

Hi unicorn.
Asking a question about a thing that I am not able to test: does sending a HUP signal to unicorn results in
connections being dropped or kept?
TIA for support

Eric Wong | 9 Jan 00:01 2016

if you want to unsubscribe

mlmmj[1] needs to know YOUR email address when you email:

	unicorn-public+unsubscribe <at>

Do NOT use "" or similar services.

They are meant for unsubscribing from marketing lists with unique
unsubscription addresses for each recipient.  That's not how
discussion list managers like mlmmj, ezmlm, or Mailman work.


Dealing with bounces and unsubscription is why I prefer people
read mailing lists over NNTP or HTTP:


You'll never need a subscription or even a valid reply
address to mail this list.
unsubscribe: unicorn-public+unsubscribe <at>