consider updating unicorn to 4.9.0

debian already has 4.9.0 and diaspora already uses it. I requested SemVer compliance from them so we could loosen depends to ~> 4.8

see http://bogomips.org/unicorn-public/560A31F1.3060608%40debian.org/t/#u for upstream comment on backword compatibility.

Added gem update label

We are working on getting 5.0.1 into debian, so if we are updating it, we could move to 5.0.1

mentioned in issue #13245 (closed)

I think @jacobvosmaer might be best suited to judge if this is doable.

http://unicorn.bogomips.org/NEWS.html

We are now on 4.6.3.

unicorn 4.9.0 - TempfileReaper support in Rack 1.6 / 2015-04-24 03:09 UTC

This release supports the Rack::TempfileReaper middleware found in rack 1.6 for cleaning up disk space used by temporary files. We also use Rack::TempfileReaper for cleaning up large temporary files buffered with TeeInput. Users on rack 1.5 and earlier will see no changes.

There's also a bunch of documentation/build system improvements.

This is likely to be the last Ruby 1.8-compatible release, unicorn 5.x will require 1.9.3 or later as well as dropping lots of cruft (the stupid "Status:" header in responses being the most notable).

21 changes backported from master:

  ISSUES: update with mailing list subscription
  FAQ: add entry for Rails autoflush_log
  dev: remove isolate dependency
  unicorn.gemspec: depend on test-unit 3.0
  remove RubyForge and Freecode references
  remove mongrel.rubyforge.org references
  examples: add run_once to before_fork hook example
  t/t0002-parser-error.sh: relax test for rack 1.6.0
  switch docs + website to olddoc
  README: clarify/reduce references to unicorn_rails
  gemspec: fixup olddoc migration
  GNUmakefile: fix clean gem build + reduce build cruft
  doc: update support status for Ruby versions
  fix uninstalled testing and reduce require paths
  test_socket_helper: do not depend on SO_REUSEPORT
  ISSUES: add section for bugs in other projects
  explain 11 byte magic number for self-pipe
  Links: mark Rainbows! as historical, reference yahns
  doc: document UNICORN_FD in manpage
  tee_input: support for Rack::TempfileReaper middleware
  support TempfileReaper in deployment and development envs

unicorn 4.8.3 - the end of an era / 2014-05-07 07:50 UTC

This release updates documentation to reflect the migration of the mailing list to a new public-inbox[1] instance. This is necessary due to the impending RubyForge shutdown on May 15, 2014.

The public-inbox address is: unicorn-public@bogomips.org (no subscription required, plain text only) ssoma[2] git archives: git://bogomips.org/unicorn-public browser-friendly archives: http://bogomips.org/unicorn-public/

Using, getting help for, and contributing to unicorn will never require any of the following:

1. non-Free software (including SaaS)
2. registration or sign-in of any kind
3. a real identity (we accept mail from Mixmaster)
4. a graphical user interface

Nowadays, plain-text email is the only ubiquitous platform which meets all our requirements for communication.

There is also one small bugfix to handle premature grandparent death upon initial startup. Most users are unaffected.

[1] policy: http://public-inbox.org/ - git://80x24.org/public-inbox an "archives first" approach to mailing lists [2] mechanism: http://ssoma.public-inbox.org/ - git://80x24.org/ssoma some sort of mail archiver (using git)

unicorn 4.8.2 - avoid race condition during worker startup / 2014-02-05 18:24 UTC

We close SELF_PIPE in the worker immediately, but signal handlers do not get setup immediately. So prevent workers from erroring out due to invalid SELF_PIPE.

unicorn 4.8.1 / 2014-01-29 08:48 UTC

fix races/error handling in worker SIGQUIT handler

This protects us from two problems:

1. we (or our app) somehow called IO#close on one of the sockets we listen on without removing it from the readers array. We'll ignore IOErrors from IO#close and assume we wanted to close it.

2. our SIGQUIT handler is interrupted by itself. This can happen as a fake signal from the master could be handled and a real signal from an outside user is sent to us (e.g. from unicorn-worker-killer) or if a user uses the killall(1) command.

unicorn 4.8.0 - big internal changes, but compatible / 2014-01-11 07:34 UTC

This release contains fairly major internal workings of master-to-worker notifications. The master process no longer sends signals to workers for most tasks. This works around some compatibility issues with some versions of the "pg" gem (and potentially any other code which may not handle EINTR properly). One extra benefit is it also helps stray workers notice a rare, unexpected master death more easily. Workers continue to (and will always) accept existing signals for compatibility with tools/scripts which may signal workers.

PID file are always written early (even on upgrade) again to avoid breaking strange monitoring setups which use PID files. Keep in mind we have always discouraged monitoring based on PID files as they are fragile.

We now avoid bubbling IOError to the Rack app on premature client disconnects when streaming the input body. This is usually not a problem with nginx, but may be on some LAN setups without nginx).

Thanks to Sam Saffron, Jimmy Soho, Rodrigo Rosenfeld Rosas, Michael Fischer, and Andrew Hobson for their help with this release.

Note: the unicorn mailing list will be moved/changed soon due to the RubyForge shutdown. unicorn will always rely only on Free Software. There will never be any sign-up requirements nor terms-of-service to agree to when communicating with us.

unicorn 4.8.0pre1 / 2013-12-09 09:51 UTC

Eric Wong (6): tests: fix SO_REUSEPORT tests for old Linux and non-Linux stream_input: avoid IO#close on client disconnect t0300: kill off stray processes in test always write PID file early for compatibility doc: clarify SIGNALS and reference init example rework master-to-worker signaling to use a pipe

unicorn 4.7.0 - minor updates, license tweak / 2013-11-04 06:59 UTC

• support SO_REUSEPORT on new listeners (:reuseport)

This allows users to start an independent instance of unicorn on a the same port as a running unicorn (as long as both instances use :reuseport).

ref: https://lwn.net/Articles/542629/

• unicorn is now GPLv2-or-later and Ruby 1.8-licensed (instead of GPLv2-only, GPLv3-only, and Ruby 1.8-licensed)

This changes nothing at the moment. Once the FSF publishes the next version of the GPL, users may choose the newer GPL version without the unicorn BDFL approving it. Two years ago when I got permission to add GPLv3 to the license options, I also got permission from all past contributors to approve future versions of the GPL. So now I'm approving all future versions of the GPL for use with unicorn.

Reasoning below:

In case the GPLv4 arrives and I am not alive to approve/review it, the lesser of evils is have give blanket approval of all future GPL versions (as published by the FSF). The worse evil is to be stuck with a license which cannot guarantee the Free-ness of this project in the future.

This unfortunately means the FSF can theoretically come out with license terms I do not agree with, but the GPLv2 and GPLv3 will always be an option to all users.

Note: we currently prefer GPLv3

Two improvements thanks to Ernest W. Durbin III:

• USR2 redirects fixed for Ruby 1.8.6 (broken since 4.1.0)
• unicorn(1) and unicorn_rails(1) enforces valid integer for -p/--port

A few more odd, minor tweaks and fixes:

• attempt to rename PID file when possible (on USR2)
• workaround reopen atomicity issues for stdio vs non-stdio
• improve handling of client-triggerable socket errors

@rspeicher I see no problems in that change list.

Milestone changed to 8.6

Added ~123454 label

mentioned in merge request !2843 (merged)

Status changed to closed by merge request !2843 (merged)

@rspeicher would it be possible to move to 5.0.1 as diaspora already moved after I first filed this bump request?

mentioned in commit 27b732ab

@pravi 5.0.1 should be doable. I didn't see potential issues for is in the changelog but will defer to @jacobvosmaer again.

mentioned in merge request !14785