dropping Ruby 1.8 support for unicorn 5? Eric Wong - 09/27
next
We've brought this up a few times, but I suppose we might as well drop
1.8 support in a major version change.

We may still maintain unicorn 4.x for 1.8 users indefinitely; after all,
we only accepted a patch for 1.8.6 compatibility less than a year
ago(!)[1].   So I'll still feel a _little_ bad for dropping 1.8 :x

One big reason for this is it looks like Ruby will move towards
deprecating old Data_* macros for superior (1.9+-only) TypedData_*
macros in the next few years[2].  The theme for unicorn 5 is mostly
dropping old, unused crap anyways; and not gaining new bloat.

Worst case is we support 1.8 and avoid deprecation warnings through
the use of ifdefs in the HTTP parser, but I'm no fan of ifdefs.


[1] commit 7e9e4c740aba24096f768f578779dc1053cb8b70
    (construct listener_fds Hash in 1.8.6 compatible way)

[2] http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=47717
    This is due to type-checking issues like
    https://bugs.ruby-lang.org/issues/10296
message raw reply permalink

  Re: dropping Ruby 1.8 support for unicorn 5? Ernest W. Durbin III - 09/27
  next prev
  As the submitter of the referenced 1.8.6 patch *still ashamed* I can say that I fully support a 4.x series with “maintenance” level support.
  
  Since the language won’t be changing, the 4.x series should be a very quiet branch indeed.
  
  Onward, to greater things.
  
  -Ernest
  
  On Sep 27, 2014, at 4:32 AM, Eric Wong <e@80x24.org> wrote:
  
  > <We've brought this up a few times, but I suppose we might as well ...>
  message raw reply parent permalink

UNSUBSCRIBE Dmytrii Nagirniak - 09/22
next prev
Can't find how I can unsub from this mailing list.
So just hoping the subject above will do it for me.

If no then I apologise for the annoyance and would appreciate the help.

Cheers.
message raw reply permalink

  Re: UNSUBSCRIBE Eric Wong - 09/22
  next prev
  Send an email to unicorn-public+unsubscribe@bogomips.org
  Follow the instructions in the confirmation email.
  
  Btw, the List-Unsubscribe: header documents this:
  List-Unsubscribe: <mailto:unicorn-public+unsubscribe@bogomips.org>
  Nearly every mailing list has the equivalent info in those headers.
  message raw reply parent permalink

    Re: UNSUBSCRIBE Dmytrii Nagirniak - 09/22
    next prev
    Thanks, appreciate it.
    Wasn't aware of it.
    
    On 22 September 2014 12:59, Eric Wong <e@80x24.org> wrote:
    > Send an email to unicorn-public+unsubscribe@bogomips.org
    > Follow the instructions in the confirmation email.
    >
    > Btw, the List-Unsubscribe: header documents this:
    > List-Unsubscribe: <mailto:unicorn-public+unsubscribe@bogomips.org>
    > Nearly every mailing list has the equivalent info in those headers.
    message raw reply parent permalink

[PATCH 0/4] a few more minor cleanups pushed out Eric Wong - 09/22
next prev
Not much going on other than killing old stuff and minor cleanups.

I'll probably give systemd a try soon and see if the
"unicorn_forever" script makes sense to bundle:
http://bogomips.org/unicorn-public/m/20130724031151.GA14534@dcvr.yhbt.net.txt

Since CoW-friendliness is important to unicorn users, I think we'll
always have to manage our own process forking.

For now, I think using the UNICORN_FD environment variable
(comma-delimited list of integer file descriptors) and matching "listen"
directives is enough to get started.  Perhaps supporting something like:

        listen :inherit

...can help DRY-up configurations so users won't have to specify
redundant listen directives.  Ruby startup times are still horrific; so
I don't think anybody wants to use socket activation with on-demand
fork+exec of unicorn processes.

The following changes since commit f203eaae7ea84de9e974ea5dac2df97d664d8e61:

  http_response: remove Status: header (2014-08-17 19:26:17 +0000)

are available in the git repository at:

  git://bogomips.org/unicorn master

for you to fetch changes up to 4b2782a926d8f131b1e7382be35e3abb77bf4be5:

  http: reduce parser from 72 to 56 bytes on 64-bit (2014-09-17 03:15:25 +0000)
more... raw reply permalink

  [PATCH 1/4] remove RubyForge and Freecode references Eric Wong - 09/22
  next prev
  Both sites are gone.
  more... raw reply parent permalink

  [PATCH 2/4] remove mongrel.rubyforge.org references Eric Wong - 09/22
  next prev
  mongrel.rubyforge.org has been dead longer than rubyforge.org!
  more... raw reply parent permalink

  [PATCH 3/4] http: remove the keepalive requests limit Eric Wong - 09/22
  next prev
  This was a hack for some event loops such as those found in nginx
  and some Rainbows! concurrency models.  Using epoll/kqueue with
  one-shot notification (which yahns does) avoids all fairness
  problems.
  more... raw reply parent permalink

  [PATCH 4/4] http: reduce parser from 72 to 56 bytes on 64-bit Eric Wong - 09/22
  next prev
  This allows the parser struct to fit in one cache line on
  x86-64 systems where cache lines are 64 bytes.
  
  Using 32-bit integer lengths is safe here because these are only for
  tracking offsets within the HTTP header buffer.  We can safely limit
  HTTP headers and in-memory buffers to be less than 4GB without
  anybody complaining.
  
  HTTP bodies continue to use off_t (usually 64-bit, even on 32-bit
  systems) sizes and support as much as the OS/hardware can handle.
  more... raw reply parent permalink

hopefully the end of *any* OobGC Eric Wong - 09/15
next prev
We may finally start deprecating OobGC, as it looks like incremental
GC[1] is working well in ruby-trunk and will make it into the Ruby
2.2.0-preview1 release (should be out soon).

I've been running unicorn.bogomips.org on ruby-trunk for most of the
year without problems, and hte past few weeks with incremental GC.
However, keep in mind I mainly serve static files (served by extras/* in
yahns.git[2]) and don't use lot of heavy-weight code.

If you find bugs in ruby-trunk itself, please report them to the
https://bugs.ruby-lang.org/ issue tracker.  That has ruby-core ML
integration[3]) so I can take a look at them.  Thanks.


[1] https://bugs.ruby-lang.org/issues/10137
[2] git clone git://yhbt.net/yahns
[3] yes, I still hate using web browsers and logins :P
message raw reply permalink

  Re: hopefully the end of *any* OobGC Bráulio Bhavamitra - 09/15
  next prev
  Eric, do you have any kind of benchmark comparing the ruby versions?
  
  On Mon, Sep 15, 2014 at 4:21 PM, Eric Wong <e@80x24.org> wrote:
  
  > <We may finally start deprecating OobGC, as it looks like incremental ...>
  more... raw reply parent permalink

    Re: hopefully the end of *any* OobGC Eric Wong - 09/15
    next prev
    Bráulio Bhavamitra <braulio@eita.org.br> wrote:
    > Eric, do you have any kind of benchmark comparing the ruby versions?
    
    See ko1's links and benchmarks in the original page.
    
    tl;dr: throughput is slightly worse, but performance is more
           consistent (fewer spikes).  Consistent performance is important
           for interactive use such as web servers.
    
    > > [1] https://bugs.ruby-lang.org/issues/10137
    
    Also, as I've told you before: please stop top-posting, sending HTML,
    and using the ridiculously large signature.  These messages get seen by
    hundreds, if not thousands of people and you're wasting precious
    bandwidth/storage/cache space for all of them.  Paying attention to
    these things is an important part of what makes unicorn work.
    
    And FWIW, I've been spending much of the past few months applying this
    philosophy to ruby-trunk and making tiny reductions in the core RubyVM
    data structures here and there, slowly working up to saving several
    hundreds of kilobytes in the hottest sections of memory (this will
    become megabytes saved with bigger Rails apps).
    
    There's much more work to be done, but the secondary goal of this is to
    get me more acquainted with VM internals more so I can dig into less
    trivial improvements.
    message raw reply parent permalink

fork() errors lead to a completely dead unicorn Jonathan del Strother - 09/03
next prev
Hi - on SmartOS & Solaris, we occasionally run into problems where
unicorn receives USR2 to reload itself, but can't fork off its workers
due to not having enough RAM.  It then kills all of its workers and
sits there failing to process any requests.  Unfortunately, the master
process stays alive - if it actually died, we'd be able to
automatically restart it.

Can we do anything to handle this more elegantly?

Jonathan

PS: An example log file from when this occurs -

I, [2014-09-03T08:51:29.034227 #7556]  INFO -- : executing
["/app/common/bundle/ruby/2.1.0/bin/unicorn", "--env",
"production-live", "--daemonize", "--config-file",
"/app/code/config/unicorn.rb", {17=>#<Kgio::TCPServer:fd 17>}] (in
/app/code)
I, [2014-09-03T08:51:29.035223 #7556]  INFO -- : forked child re-executing...
I, [2014-09-03T08:51:30.480393 #7556]  INFO -- : inherited
addr=0.0.0.0:8090 fd=17
I, [2014-09-03T08:51:30.481257 #7556]  INFO -- : Refreshing Gem list
D, [2014-09-03T08:51:41.715061 #7556] DEBUG -- : ** [Airbrake]
Notifier 3.1.14 ready to catch errors
I, [2014-09-03T08:51:45.437499 #7952]  INFO -- : worker=0 ready
I, [2014-09-03T08:51:45.471084 #7959]  INFO -- : worker=1 ready
I, [2014-09-03T08:51:45.513301 #7960]  INFO -- : worker=2 ready
I, [2014-09-03T08:51:45.558417 #7961]  INFO -- : worker=3 ready
E, [2014-09-03T08:51:45.931282 #7556] ERROR -- : Not enough space -
fork(2) (Errno::ENOMEM)
/app/common/bundle/ruby/2.1.0/gems/unicorn-4.8.3/lib/unicorn/http_server.rb:520:in
`fork'
/app/common/bundle/ruby/2.1.0/gems/unicorn-4.8.3/lib/unicorn/http_server.rb:520:in
`spawn_missing_workers'
/app/common/bundle/ruby/2.1.0/gems/unicorn-4.8.3/lib/unicorn/http_server.rb:140:in
`start'
/app/common/bundle/ruby/2.1.0/gems/unicorn-4.8.3/bin/unicorn:126:in
`<top (required)>'
/app/common/bundle/ruby/2.1.0/bin/unicorn:23:in `load'
/app/common/bundle/ruby/2.1.0/bin/unicorn:23:in `<main>'
E, [2014-09-03T08:51:46.139737 #10484] ERROR -- : reaped
#<Process::Status: pid 7556 exit 1> exec()-ed
I, [2014-09-03T08:51:48.069452 #10484]  INFO -- : reaped
#<Process::Status: pid 21801 exit 0> worker=1
I, [2014-09-03T08:51:48.372431 #10484]  INFO -- : reaped
#<Process::Status: pid 67829 exit 0> worker=3
I, [2014-09-03T08:51:48.473412 #10484]  INFO -- : reaped
#<Process::Status: pid 57211 exit 0> worker=0
I, [2014-09-03T08:51:48.574279 #10484]  INFO -- : reaped
#<Process::Status: pid 70992 exit 0> worker=2
I, [2014-09-03T08:51:48.675085 #10484]  INFO -- : reaped
#<Process::Status: pid 11195 exit 0> worker=5
I, [2014-09-03T08:51:48.876051 #10484]  INFO -- : reaped
#<Process::Status: pid 11194 exit 0> worker=4
I, [2014-09-03T08:51:48.876341 #10484]  INFO -- : master complete
message raw reply permalink

  Re: fork() errors lead to a completely dead unicorn Eric Wong - 09/03
  next prev
  Jonathan del Strother <maillist@steelskies.com> wrote:
  > Hi - on SmartOS & Solaris, we occasionally run into problems where
  > unicorn receives USR2 to reload itself, but can't fork off its workers
  > due to not having enough RAM.  It then kills all of its workers and
  > sits there failing to process any requests.  Unfortunately, the master
  > process stays alive - if it actually died, we'd be able to
  > automatically restart it.
  
  I wonder if this is an SMF problem.  At the bottom of your log,
  it says "master complete", which seems to be the master which received
  the USR2.
  
  I'll walk through the log to see how things look from my end...
  
  > Can we do anything to handle this more elegantly?
  
  > PS: An example log file from when this occurs -
  > 
  > I, [2014-09-03T08:51:29.034227 #7556]  INFO -- : executing
  > ["/app/common/bundle/ruby/2.1.0/bin/unicorn", "--env",
  > "production-live", "--daemonize", "--config-file",
  
  7556 is the new child which eventually fails.
  
  > <"/app/code/config/unicorn.rb", {17=>#<Kgio::TCPServer:fd ...>
  
  OK, fork fails from the new child; current behavior is to exit.
  
  > /app/common/bundle/ruby/2.1.0/gems/unicorn-4.8.3/lib/unicorn/http_server.rb:520:in
  > `fork'
  > /app/common/bundle/ruby/2.1.0/gems/unicorn-4.8.3/lib/unicorn/http_server.rb:520:in
  > `spawn_missing_workers'
  > /app/common/bundle/ruby/2.1.0/gems/unicorn-4.8.3/lib/unicorn/http_server.rb:140:in
  > `start'
  > /app/common/bundle/ruby/2.1.0/gems/unicorn-4.8.3/bin/unicorn:126:in
  > `<top (required)>'
  
  OK, this should've hit the exit! case in spawn_missing_workers,
  and it does...
  
  > /app/common/bundle/ruby/2.1.0/bin/unicorn:23:in `load'
  > /app/common/bundle/ruby/2.1.0/bin/unicorn:23:in `<main>'
  > E, [2014-09-03T08:51:46.139737 #10484] ERROR -- : reaped
  > #<Process::Status: pid 7556 exit 1> exec()-ed
  
  old master which originally received USR2 is notified the new master
  (7556) died
  
  > I, [2014-09-03T08:51:48.069452 #10484]  INFO -- : reaped
  > #<Process::Status: pid 21801 exit 0> worker=1
  > I, [2014-09-03T08:51:48.372431 #10484]  INFO -- : reaped
  > #<Process::Status: pid 67829 exit 0> worker=3
  > I, [2014-09-03T08:51:48.473412 #10484]  INFO -- : reaped
  > #<Process::Status: pid 57211 exit 0> worker=0
  > I, [2014-09-03T08:51:48.574279 #10484]  INFO -- : reaped
  > #<Process::Status: pid 70992 exit 0> worker=2
  > I, [2014-09-03T08:51:48.675085 #10484]  INFO -- : reaped
  > #<Process::Status: pid 11195 exit 0> worker=5
  > I, [2014-09-03T08:51:48.876051 #10484]  INFO -- : reaped
  > #<Process::Status: pid 11194 exit 0> worker=4
  
  Workers in the old master dying looks like the SMF problem you
  encountered with SIGABRT earlier.
  
  > I, [2014-09-03T08:51:48.876341 #10484]  INFO -- : master complete
  
  But the original master does not die after this?
  
  Can you truss it and see if it's stuck on reading/unlinking the pidfile?
  That would the only thing preventing the master from actually dying,
  but the old master dying should not happen in the first place.
  more... raw reply parent permalink

    Re: fork() errors lead to a completely dead unicorn Jonathan del Strother - 09/07
    next prev
    Just wanted to say thanks for the reply - I've been trying to figure
    this out over the weekend and not succeeding.  I can't seem to
    reproduce it in a self-contained environment, it only ever happens in
    production, which is making debugging a bit frustrating...
    
    >
    >> I, [2014-09-03T08:51:48.876341 #10484]  INFO -- : master complete
    >
    > But the original master does not die after this?
    
    99% sure it doesn't - it just sits there in a zombie state with no
    workers.  But I want to verify that, so I guess I'm stuck waiting
    until it happens in production again.  Will let you know.
    message raw reply parent permalink

Worker SIGABRT takes down all workers? Jonathan del Strother - 08/21
next prev
Hi there,
We're trying to figure out a problem we're having where Ruby 2.1.2 /
ImageMagick is causing a SIGABRT in a unicorn worker process.  When it
does so, I see this in unicorn.log :

I, [2014-08-21T11:40:44.282905 #65706]  INFO -- : reaped
#<Process::Status: pid 66787 exit 0> worker=0
I, [2014-08-21T11:40:44.283289 #65706]  INFO -- : reaped
#<Process::Status: pid 66801 exit 0> worker=7
I, [2014-08-21T11:40:44.283583 #65706]  INFO -- : reaped
#<Process::Status: pid 66790 exit 0> worker=3
I, [2014-08-21T11:40:44.283871 #65706]  INFO -- : reaped
#<Process::Status: pid 66793 exit 0> worker=4
I, [2014-08-21T11:40:44.284198 #65706]  INFO -- : reaped
#<Process::Status: pid 66794 exit 0> worker=5
I, [2014-08-21T11:40:44.284538 #65706]  INFO -- : reaped
#<Process::Status: pid 66798 exit 0> worker=6
I, [2014-08-21T11:40:44.284832 #65706]  INFO -- : reaped
#<Process::Status: pid 66788 exit 0> worker=1
E, [2014-08-21T11:40:44.385491 #65706] ERROR -- : reaped
#<Process::Status: pid 66789 SIGABRT (signal 6) (core dumped)>
worker=2
I, [2014-08-21T11:40:44.385951 #65706]  INFO -- : master complete
I, [2014-08-21T11:40:48.073191 #72528]  INFO -- : Refreshing Gem list
I, [2014-08-21T11:41:06.841582 #72528]  INFO -- : listening on
addr=0.0.0.0:8090 fd=17

So, as far as I can tell, the SIGABRT in a worker causes all siblings
workers to be reaped and restarted.   Is that intended/expected?
Shouldn't it just kill the single worker & restart that?

-Jonathan
message raw reply permalink

  Re: Worker SIGABRT takes down all workers? Eric Wong - 08/21
  next prev
  Jonathan del Strother <jon.delStrother@audioboo.fm> wrote:
  > So, as far as I can tell, the SIGABRT in a worker causes all siblings
  > workers to be reaped and restarted.   Is that intended/expected?
  > Shouldn't it just kill the single worker & restart that?
  
  Not intended or expected.  I cannot reproduce it by doing:
  
  	kill -ABRT $WORKER_PID
  
  Can you?
  Can you setup a small test case which reproduces the issue?
  Is anything else running that could be sending signals to all workers?
  
  Thanks for any more info you can provide.
  message raw reply parent permalink

    Re: Worker SIGABRT takes down all workers? Jonathan del Strother - 08/22
    next prev
    On 21 August 2014 21:32, Eric Wong <e@80x24.org> wrote:
    > Jonathan del Strother <jon.delStrother@audioboo.fm> wrote:
    >> So, as far as I can tell, the SIGABRT in a worker causes all siblings
    >> workers to be reaped and restarted.   Is that intended/expected?
    >> Shouldn't it just kill the single worker & restart that?
    >
    > Not intended or expected.  I cannot reproduce it by doing:
    >
    >         kill -ABRT $WORKER_PID
    >
    
    You're quite right, sorry.  I'm running via SMF, which is detecting
    the child process's SIGABRT and deciding to restart the entire group.
    I'll look into getting SMF to ignore those.
    message raw reply parent permalink

more house-cleaning for unicorn 5 Eric Wong - 08/17
next prev
The only user-visible change would be the removal of the Status:
header from the HTTP response, but I doubt anybody would even
notice.

Eric Wong (3):
      dev: remove isolate dependency
      unicorn.gemspec: depend on test-unit 3.0
      http_response: remove Status: header
message raw reply permalink

  [PATCH 1/3] dev: remove isolate dependency Eric Wong - 08/17
  next prev
  It seems unnecessary with current versions of RubyGems
  supporting development dependencies.
  more... raw reply parent permalink

  [PATCH 2/3] unicorn.gemspec: depend on test-unit 3.0 Eric Wong - 08/17
  next prev
  test-unit 3 and minitest 5 will have equal support status as a
  bundled gems when Ruby 2.2.0 is released in December 2014.  These
  bundled gems will appear in the user-oriented tarball installations,
  but do not get installed by "make install" when installing Ruby
  from SVN or git.
  
  test-unit appears to be actively maintained and good at keeping
  backwards compatibility even on a major version change, so this
  means no code changes on our end.  I am not convinced switching to
  minitest is worth the effort.
  
  Cc: Ken Dreyer <ktdreyer@ktdreyer.com>
  more... raw reply parent permalink

  [PATCH 3/3] http_response: remove Status: header Eric Wong - 08/17
  next prev
  Whatever compatibility reasons which existed in 2009 likely do not exist
  now.  Other servers (e.g. thin, puma) seem to work alright without it,
  so there's no reason to waste precious bytes.
  more... raw reply parent permalink

Re: Weird Unicorn Timeout Issues (Hibernation problem?) Tony Devlin - 08/06
next prev
Eric,

The problem is a firewall that sits between the servers and the database.
 It is an idle session timeout of 30 minutes, so it is silently killing the
connection.  I have reached out to our Network Engineering department but
they are saying they can not change that idle session timeout, nor create a
special rule to allow this connection to bypass that rule.

Currently, I setup a polling device that calls the applications URL every
20 minutes.  This causes the connection between the server and DB to
refresh it's idle timeout.  This is obviously a very hacky way to handle
it, so I am trying to look into AR and Oracle_Enhanced to see if they have
some sort of keepalive option for the database.  I thought it would work
with the reaping_frequency, but apparently that does not work out as I had
expected when you are not running in pools or a thread.  So I'm still on
the lookout for something to handle that.




On Wed, Aug 6, 2014 at 5:45 AM, Eric Wong <e@80x24.org> wrote:
> <> > Any update? It looks like your DB driver is not ...>
message raw reply parent permalink

  Re: Weird Unicorn Timeout Issues (Hibernation problem?) Daniel Condomitti - 08/06
  next prev
  This is exactly what happened to us and I should have been clearer. I wasn’t referring to the default Linux kernel settings causing the killing the connection; it was a network device between our application servers and the database server. It only affected certain applications as some were hit hundreds of times per second and would never be disconnected and the ones that would disconnect were only hit a few times per hour. I -believe- we just dropped the keepalive interval on both sides of the firewall below its idle timeout.  
  
  
  On Wednesday, August 6, 2014 at 7:05 AM, Tony Devlin wrote:
  
  > <Eric, > > The problem is a firewall that sits between the servers ...>
  message raw reply parent permalink


page: next      atom permalink
- unicorn Rack HTTP server user/dev discussion
A public-inbox, anybody may post in plain-text (not HTML):
unicorn-public@bogomips.org
git URL for ssoma: git://bogomips.org/unicorn-public.git
homepage: http://unicorn.bogomips.org/
subscription optional: unicorn-public+subscribe@bogomips.org