Eric Wong | 20 Jun 22:00 2016

[PATCH] examples/logrotate.conf: update example for systemd

...And add placeholders for other systems
  Leaving out the part for using a backup service :>

	for i in /var/log/unicorn_app/*.log.gz
		curl -sSf -T $i && rm $i

 examples/logrotate.conf | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/examples/logrotate.conf b/examples/logrotate.conf
index 03fefc6..437f6c6 100644
--- a/examples/logrotate.conf
+++ b/examples/logrotate.conf
 <at>  <at>  -3,6 +3,9  <at>  <at> 
 # See the logrotate(8) manpage for more information:
+# public logrotate-related discussion in our archives:

 # Modify the following glob to match the logfiles your app writes to:
 /var/log/unicorn_app/*.log {
 <at>  <at>  -22,7 +25,19  <at>  <at> 
 	# config.  Unicorn supports the USR1 signal and we send it
 	# as our "lastaction" action:
(Continue reading)

Eric Wong | 14 Jun 00:31 2016

[PATCH] doc: systemd should only kill master in example

By default, systemd kills every process in the control group
when stopping a service.  While it ought to be harmless to
signal workers, some Rack applications (and perhaps further
subprocesses) can misbehave when interrupted by a signal.
Ensure we only hit the master on graceful shutdown to avoid
tickling bugs in Rack apps.

This is the reason we switched to having the master send
"fake" signals for workers beginning with unicorn 4.8.0
back in 2013/2014.
 examples/unicorn <at> .service | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/examples/unicorn <at> .service b/examples/unicorn <at> .service
index 56aaec8..d95eb83 100644
--- a/examples/unicorn <at> .service
+++ b/examples/unicorn <at> .service
 <at>  <at>  -24,5 +24,10  <at>  <at>  ExecReload = /bin/kill -HUP $MAINPID
 # adding a few seconds for scheduling differences:
 TimeoutStopSec = 62

+# Only kill the master process, it may be harmful to signal
+# workers via default "control-group" setting since some
+# Ruby extensions and applications misbehave on interrupts
+KillMode = process
 WantedBy =
(Continue reading)

Eric Wong | 7 Jun 15:41 2016

Re: [PATCH] `unicorn upgrade` script resilience against exceptions

Jesper Rønn-Jensen <jesperrr <at>> wrote:
> This is actually a change proposal "by accident". But first, some
> background:

	Please don't send HTML mail.  I guess the bounce message didn't
	include the reason for the bounce, but should be fixed; now;
	and the bounce will tell you to not send HTML.

	Anyways if you stick to old-school Usenet/mailing list posting
	conventions, I'm more than happy to help you :)

> My server uses a standard version of this `` script. I found that
> executing `unicorn upgrade` often gives me problems.

Hm... I haven't looked at that script in a while given all
the new-fangled init replacements...

> For example, it breaks my Capistrano deploy script to use `unicorn:upgrade`
> to deploy. This is a shame, since it's the correct
> command for Unicorn to pick up any code changes. But unicorn upgrade in the
> script fails with messages like:
> ```
> sudo /etc/init.d/unicorn upgrade
> Couldn't upgrade, starting 'export HOME=/home/deploy ; cd
> /var/www/my_app/current && /home/deploy/.rvm/wrappers/my_app/bundle exec
> unicorn -D -c /var/www/my_app/shared/config/unicorn.rb -E production'
> instead
> master failed to start, check stderr log for details
> ```
(Continue reading)

Eric Wong | 26 May 23:57 2016

Re: Unicorn is a famous and widely use software, but why official website look so outdate?

Zheng Cheng <guokrfans <at>> wrote:

Please don't send HTML email; it is bloated, spammy and your
mail got stuck in my spam filter instead of hitting the list.

About the Subject, unicorn itself is outdated by design:

This list rejecting HTML is another "outdated" characteristic
of the project :)

Being outdated is not bad IMHO; more of us had slower computers
and connections back then and needed to make every byte matter.
Many "modern" websites are slow and inaccessible to poor and/or
low-eyesight users.

The CSS on the old website was as big as the README page;
slowing or even breaking rendering.  Nowadays it does not depend
on CSS at all, and is designed to reduce scrolling for users
on small screens (or big screens and giant fonts :)

Enabling CSS may also be dangerous:

Slow connections still come from poorer areas and even the
well-off have connectivity trouble over Tor or mobile.  Some of
us have bad eyesight and need gigantic fonts and custom colors
(Continue reading)

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)