Unicorn homepage design
- by Tommaso Pavese @ 05/03 09:19 UTC - next

Hello,

Unicorn’s homepage (http://unicorn.bogomips.org/) seems to have lost CSS and JS.

Is it because of the shutdown of Rubyforge?
E.g. the content was moved elsewhere, but the darkfish rdoc template was provided by Rubyforge?
I can’t remember if it was hosted there or not.

Is anyone already working on the issue?
If not, do you need any help?

Cheers,
Tom

message raw reply threadlink

  Re: Unicorn homepage design
  - by Hleb Valoshka @ 13:23 UTC - next/prev

  On 5/3/15, Tommaso Pavese <tommaso@pavese.me> wrote:
  > Unicorn’s homepage (http://unicorn.bogomips.org/) seems to have lost CSS and
  > JS.
  
  It has no js/css at all :) Pretty good hypertext :)

  message raw reply parent threadlink

  Re: Unicorn homepage design
  - by Eric Wong @ 17:20 UTC - next/prev

  Tommaso Pavese <tommaso@pavese.me> wrote:
  > Hello,
  > 
  > Unicorn’s homepage (http://unicorn.bogomips.org/) seems to have lost
  > CSS and JS.
  
  I switched to olddoc recently to get rid of CSS/images and haven't
  used JS for several years before that:
  
  http://bogomips.org/unicorn-public/m/20150110044934.GA1328@dcvr.yhbt.net.html
  
  It uses the olddoc document generator: http://80x24.org/olddoc/
  
  > If not, do you need any help?
  
  Nothing directly with unicorn, but the cgit web viewer at
  http://bogomips.org/unicorn.git/ still has CSS.
  
  It would be nice to make CSS optional in cgit so webmasters can disable
  it.  There might be a place where it uses a on* hook for JS, too, so
  that should be disable-able via config option.  Obviously I disabled
  the logo long ago :)
  
  Contributing to cgit is identical to git itself and unicorn,
  except the mailing list requires subscription.
  
  subscribe: cgit-request@lists.zx2c4.com?subject=subscribe
  post: cgit@lists.zx2c4.com

  message raw reply parent threadlink

[ANN] unicorn 4.9.0 - Rack HTTP server for fast clients and *nix
- by Eric Wong @ 04/24 03:17 UTC - next/prev

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.

* http://unicorn.bogomips.org/
* public list: unicorn-public@bogomips.org
* mail archives: http://bogomips.org/unicorn-public/
* git clone git://bogomips.org/unicorn.git
* http://unicorn.bogomips.org/NEWS.atom.xml

Changes:

  unicorn 4.9.0 - TempfileReaper support in Rack 1.6

  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

more... raw reply threadlink

[PATCH 0/2] Rack::TempfileReaper support
- by Eric Wong @ 04/24 03:02 UTC - next/prev

These will be in the upcoming 4.9 release, as well as the 5.x
release which drops old cruft and 1.8 support.  I've decided
to use 4.9 instead of 4.8.4 since this does change the feature
set slightly.

Eric Wong (2):
      tee_input: support for Rack::TempfileReaper middleware
      support TempfileReaper in deployment and development envs

 lib/unicorn.rb              |  2 ++
 lib/unicorn/tee_input.rb    |  9 ++++++++-
 lib/unicorn/tmpio.rb        |  3 +++
 test/unit/test_tee_input.rb | 10 ++++++++++
 4 files changed, 23 insertions(+), 1 deletion(-)

message raw reply threadlink

  [PATCH 1/2] tee_input: support for Rack::TempfileReaper middleware
  - by Eric Wong @ 04/24 03:02 UTC - next/prev

  Rack::TempfileReaper was added in rack 1.6 to cleanup temporary
  files.  Make Unicorn::TmpIO ducktype-compatible so
  Rack::TempfileReaper may be used to free up space used by temporary
  buffer files.
  
  Ref: <CY1PR0301MB078011EB5A22B733EB222A45A4EE0@CY1PR0301MB0780.namprd03.prod.outlook.com>
  Reported-by: Mike Mulvaney <MMulvaney@bna.com>

  more... raw reply parent threadlink

  [PATCH 2/2] support TempfileReaper in deployment and development envs
  - by Eric Wong @ 04/24 03:02 UTC - next/prev

  rack 1.6 added a TempfileReaper middleware to cleanup temporary
  files.  Enable it by default for users running rack 1.6 or later
  to avoid leaving temporary files around.

  more... raw reply parent threadlink

Will restarting a Unicorn process (via HUP signal) wait for worker threads?
- by Jason Hines @ 04/24 00:04 UTC - next/prev

In my application, I have some background jobs which are executed in
separate threads.  (using SuckerPunch/Celluloid framework)

If I send a HUP signal to the Unicorn master, the application is reloaded
and gracefully restarts the workers.    But, if those workers have child
threads, does Unicorn wait for those threads to finish before the restart
or are they terminated immediately?

Thanks in advance for any light shed here.

message raw reply threadlink

  Re: Will restarting a Unicorn process (via HUP signal) wait for worker threads?
  - by Eric Wong @ 04/24 00:13 UTC - next/prev

  Jason Hines <jason@greenhell.com> wrote:
  > In my application, I have some background jobs which are executed in
  > separate threads.  (using SuckerPunch/Celluloid framework)
  > 
  > If I send a HUP signal to the Unicorn master, the application is reloaded
  > and gracefully restarts the workers.    But, if those workers have child
  > threads, does Unicorn wait for those threads to finish before the restart
  > or are they terminated immediately?
  
  unicorn itself does not know about any threads spawned by the application.
  
  However, you can setup an END/at_exit block in the worker to wait on
  those threads since unicorn workers perform graceful exit:
  
  	at_exit do
  	  join_all_threads
  	end

  message raw reply parent threadlink

Unicorn, environment variables, start and reload
- by Jérémy Lecour @ 04/23 09:05 UTC - next/prev

Hi,

For some time I've been using Unicorn to serve Rails applications.

I've been increasingly relying on environment variables to set various
password and configuration bits outside of the application's code.

For that I've been using the "dotenv" gem that load a `.env` file into
the ENV hash. It's great and really useful in development mode, but
it's not a best practice to use it in production. Here is what Brandon
Keepers (maintainer of Dotenv) says about this :

> One of the reasons I don't advocate for using dotenv in production is because it loads the environment variables within the ruby process, which makes it very difficult to track which variables were previously set and which were loaded by dotenv. If you set these variables in the environment of your server (/etc/environment, /etc/profile, etc) then unicorn reloading will just work.

So I was wondering what would be the correct way to have environment
variables available in the Ruby process, up-to-date when the Unicorn
process is started and reloaded too (with USR2).

And there is also the case of various shell initializations
(login/non-login, interactive/non-interactive) and supervisors like
Monit that strip the environment to a minumum before executing the
start/stop commands.

I understand that I can do something like this on start :

    $ source ~/my/app/.env && unicorn [...]

But what about the reload situation ?


Thanks for the help.

more... raw reply threadlink

  Re: Unicorn, environment variables, start and reload
  - by Eric Wong @ 04/23 09:29 UTC - next/prev

  Jérémy Lecour <jeremy.lecour@gmail.com> wrote:
  > <Hi, > > For some time I've been using Unicorn to serve Rails ...>
  
  Right, and some of these envs might not work unless they're set before
  Ruby VM initialization.  By the time the process can run Ruby code, it's
  too late to setup most malloc behavior in any program or GC tuning for
  Ruby.
  
  I think most of the MRI-specific RUBY_* vars and most enviroment
  variables used for any malloc tuning will fall into this group.
  
  > So I was wondering what would be the correct way to have environment
  > variables available in the Ruby process, up-to-date when the Unicorn
  > process is started and reloaded too (with USR2).
  > 
  > And there is also the case of various shell initializations
  > (login/non-login, interactive/non-interactive) and supervisors like
  > Monit that strip the environment to a minumum before executing the
  > start/stop commands.
  
  I set them in an init script (or whatever startup script/system I use).
  I might also use "env -i" to clobber any existing environment if
  I'm feeling really thorough, but usually I don't.
  
  Most versions of Linux allow checking the environment by inspecting
  /proc/$PID/environ  (tr '\0' '\n' </proc/$PID/environ to convert
  null-terminated to newlines).  This may not reflect changes done inside
  the process, though, so maybe have a private endpoint dump the contents
  of ENV.
  
  > I understand that I can do something like this on start :
  > 
  >     $ source ~/my/app/.env && unicorn [...]
  > 
  > But what about the reload situation ?
  
  You can change the ENV (or run any other Ruby) in the config file, but
  most might not take effect until a new process is spawned (same with
  dotenv).  This means you may need USR2 for it to take effect.
  
  I definitely keep ENV changes in the Ruby config file synched with
  what's in the init script (and both in version control).

  message raw reply parent threadlink

unicorn 4.8.x-stable branch pushed to git
- by Eric Wong @ 04/22 19:02 UTC - next/prev

Only backporting documentation + build/test system fixes, but I'll
probably apply and push the TeeInput patch in:
http://bogomips.org/unicorn-public/m/20150422183808.GA5277@dcvr.yhbt.net.txt

The following changes since commit 7087bb7ed5a1b9d9f24069cb92707d086668b6dc:

  unicorn 4.8.3 - the end of an era (2014-05-07 07:49:19 +0000)

are available in the git repository at:

  git://bogomips.org/unicorn 4.8.x-stable

for you to fetch changes up to 548e1e67d314f6ebd17df37ece0ee20632462f6f:

  doc: document UNICORN_FD in manpage (2015-04-22 18:57:39 +0000)

more... raw reply threadlink

TeeInput leaks file handles/space
- by Mulvaney, Mike @ 04/22 16:42 UTC - next/prev

When I upload large files to my unicorn process, TeeInput is streaming them through a @tmp instance variable which writes to /tmp/0.123456789 (some random number).  The file is immediately deleted but the file handle is not closed, so the files are not really deleted by the file system.

The files are eventually deleted when GC runs, but before GC runs they continue to take up space.  You can see this in lsof output, for example:

ruby       2783   webuser  23u      REG               0,17  6128086    3556917 /tmp/0.04249158625633187 (deleted)

This can cause problems if you have big files and a small /tmp, such as a tmpfs disk mounted in ram.  If someone sends in several 100MB files, you could easily get 2-3 open files for each of 6 unicorn processes, which would take up 1200MB of disk space until GC decides to run.

I looked into fixing this but it doesn't look easy.  I can reach into the TeeInput variable and close out the @tmp instance variable in my application, and that does fix the problem.  But obviously that is not a good solution.  I think there would have to be some kind of "close" method on http_request that would close out all the open resources such as these files.

-Mike

message raw reply threadlink

  Re: TeeInput leaks file handles/space
  - by Eric Wong @ 04/22 18:38 UTC - next/prev

  How about this patch to tee_input?  It won't pollute the common code
  path, at least, and unicorn won't support multiple clients/tee_inputs
  
  I might release 4.8.4 with this, but it does break behavior for
  hijackers, but 5.0 will have lots of tiny internal incompatibilities
  for corner-cases anyways.
  -----------------------------8<---------------------------
  Subject: [PATCH] tee_input: close temporary file upon allocating the next
  
  This prevents unicorn from using up too much space due to large
  uploads while not polluting the common code path of most clients.
  
  This is only fine for unicorn since unicorn itself will never
  support multiple clients in the same process.
  
  This may break users of rack.hijack (are there any on unicorn?), but
  they can call IO#dup on the file if they're relying on hijack and
  server internals like that.
  
  In a perfect world, we could even truncate and rewind to avoid the
  FD/inode deallocation/allocations in the kernel; but that would
  break any IO#dup workarounds used by hijackers.
  
  Notes: StringIO#close does not release memory immediately, so
  there's no point in calling it here
  
  Ref: <CY1PR0301MB078011EB5A22B733EB222A45A4EE0@CY1PR0301MB0780.namprd03.prod.outlook.com>
  Reported-by: Mike Mulvaney <MMulvaney@bna.com>

  more... raw reply parent threadlink

    RE: TeeInput leaks file handles/space
    - by Mulvaney, Mike @ 04/22 19:10 UTC - next/prev

    That looks reasonable to me -- this way you would only have one file still open per process at a maximum, right?  I think that's a good solution.
    
    Thanks,
    
    -Mike
    
    -----Original Message-----
    From: Eric Wong [mailto:e@80x24.org] 
    Sent: Wednesday, April 22, 2015 2:38 PM
    To: Mulvaney, Mike
    Cc: unicorn-public@bogomips.org
    Subject: Re: TeeInput leaks file handles/space
    
    How about this patch to tee_input?  It won't pollute the common code path, at least, and unicorn won't support multiple clients/tee_inputs
    
    I might release 4.8.4 with this, but it does break behavior for hijackers, but 5.0 will have lots of tiny internal incompatibilities for corner-cases anyways.
    -----------------------------8<---------------------------
    Subject: [PATCH] tee_input: close temporary file upon allocating the next
    
    This prevents unicorn from using up too much space due to large uploads while not polluting the common code path of most clients.
    
    This is only fine for unicorn since unicorn itself will never support multiple clients in the same process.
    
    This may break users of rack.hijack (are there any on unicorn?), but they can call IO#dup on the file if they're relying on hijack and server internals like that.
    
    In a perfect world, we could even truncate and rewind to avoid the FD/inode deallocation/allocations in the kernel; but that would break any IO#dup workarounds used by hijackers.
    
    Notes: StringIO#close does not release memory immediately, so there's no point in calling it here
    
    Ref: <CY1PR0301MB078011EB5A22B733EB222A45A4EE0@CY1PR0301MB0780.namprd03.prod.outlook.com>
    Reported-by: Mike Mulvaney <MMulvaney@bna.com>

    more... raw reply parent threadlink

      Re: TeeInput leaks file handles/space
      - by Eric Wong @ 04/22 19:16 UTC - next/prev

      "Mulvaney, Mike" <MMulvaney@bna.com> wrote:
      > That looks reasonable to me -- this way you would only have one file
      > still open per process at a maximum, right?  I think that's a good
      > solution.
      
      Right.
      
      Below is a barely-tested alternative patch for Rack::TempfileReaper,
      for Rack 1.6+ users only.  I'm not sure how prevalent 1.6+ was only
      released in December 2014...
      
      It's more standardized, but maybe Rack 1.6 isn't prevalent enough, yet.
      What do you think?
      
      (Sorry, in a rush, no commit message, yet)
      
      diff --git a/lib/unicorn/tee_input.rb b/lib/unicorn/tee_input.rb
      index 637c583..7f6baa2 100644
      --- a/lib/unicorn/tee_input.rb
      +++ b/lib/unicorn/tee_input.rb
      @@ -28,13 +28,20 @@ class Unicorn::TeeInput < Unicorn::StreamInput
           @@client_body_buffer_size
         end
       
      +  # for Rack::TempfileReaper in rack 1.6+
      +  def new_tmpio
      +    tmpio = Unicorn::TmpIO.new
      +    (@parser.env['rack.tempfiles'] ||= []) << tmpio
      +    tmpio
      +  end
      +
         # Initializes a new TeeInput object.  You normally do not have to call
         # this unless you are writing an HTTP server.
         def initialize(socket, request)
           @len = request.content_length
           super
           @tmp = @len && @len <= @@client_body_buffer_size ?
      -           StringIO.new("") : Unicorn::TmpIO.new
      +           StringIO.new("") : new_tmpio
         end
       
         # :call-seq:
      diff --git a/lib/unicorn/tmpio.rb b/lib/unicorn/tmpio.rb
      index c97979a..db88ed3 100644
      --- a/lib/unicorn/tmpio.rb
      +++ b/lib/unicorn/tmpio.rb
      @@ -21,4 +21,7 @@ class Unicorn::TmpIO < File
           fp.sync = true
           fp
         end
      +
      +  # pretend we're Tempfile for Rack::TempfileReaper
      +  alias close! close
       end

      message raw reply parent threadlink

        RE: TeeInput leaks file handles/space
        - by Mulvaney, Mike @ 04/22 19:24 UTC - next/prev

        Oh yeah, I like that even better.
        
        The app I'm currently working on is using Rails 4.1 and Rack 1.5.x.  I don't have any problem with upgrading rack, I just haven't done it yet.
        
        I think it would be reasonable to fix this for Rack 1.6+.  It won't cause any problems for Rack 1.5 users, right?  The environment variable gets set and then ignored, so the app would behave exactly the same way.  If they want to use the new cleanup code, they can upgrade rack.
        
        -Mike
        
        -----Original Message-----
        From: Eric Wong [mailto:e@80x24.org] 
        Sent: Wednesday, April 22, 2015 3:16 PM
        To: Mulvaney, Mike
        Cc: unicorn-public@bogomips.org
        Subject: Re: TeeInput leaks file handles/space
        
        "Mulvaney, Mike" <MMulvaney@bna.com> wrote:
        > That looks reasonable to me -- this way you would only have one file 
        > still open per process at a maximum, right?  I think that's a good 
        > solution.
        
        Right.
        
        Below is a barely-tested alternative patch for Rack::TempfileReaper, for Rack 1.6+ users only.  I'm not sure how prevalent 1.6+ was only released in December 2014...
        
        It's more standardized, but maybe Rack 1.6 isn't prevalent enough, yet.
        What do you think?
        
        (Sorry, in a rush, no commit message, yet)
        
        diff --git a/lib/unicorn/tee_input.rb b/lib/unicorn/tee_input.rb index 637c583..7f6baa2 100644
        --- a/lib/unicorn/tee_input.rb
        +++ b/lib/unicorn/tee_input.rb
        @@ -28,13 +28,20 @@ class Unicorn::TeeInput < Unicorn::StreamInput
             @@client_body_buffer_size
           end
         
        +  # for Rack::TempfileReaper in rack 1.6+  def new_tmpio
        +    tmpio = Unicorn::TmpIO.new
        +    (@parser.env['rack.tempfiles'] ||= []) << tmpio
        +    tmpio
        +  end
        +
           # Initializes a new TeeInput object.  You normally do not have to call
           # this unless you are writing an HTTP server.
           def initialize(socket, request)
             @len = request.content_length
             super
             @tmp = @len && @len <= @@client_body_buffer_size ?
        -           StringIO.new("") : Unicorn::TmpIO.new
        +           StringIO.new("") : new_tmpio
           end
         
           # :call-seq:
        diff --git a/lib/unicorn/tmpio.rb b/lib/unicorn/tmpio.rb index c97979a..db88ed3 100644
        --- a/lib/unicorn/tmpio.rb
        +++ b/lib/unicorn/tmpio.rb
        @@ -21,4 +21,7 @@ class Unicorn::TmpIO < File
             fp.sync = true
             fp
           end
        +
        +  # pretend we're Tempfile for Rack::TempfileReaper  alias close! close
         end

        message raw reply parent threadlink

          Re: TeeInput leaks file handles/space
          - by Eric Wong @ 04/24 03:08 UTC - next/prev

          "Mulvaney, Mike" <MMulvaney@bna.com> wrote:
          > I think it would be reasonable to fix this for Rack 1.6+.  It won't
          > cause any problems for Rack 1.5 users, right?  The environment
          > variable gets set and then ignored, so the app would behave exactly
          > the same way.  If they want to use the new cleanup code, they can
          > upgrade rack.
          
          Right, this only affects 1.6 users.  1.5 users will need to upgrade for
          this.

          message raw reply parent threadlink

            Re: TeeInput leaks file handles/space
            - by Mulvaney, Mike @ 04/24 11:56 UTC - next/prev

            That sounds great. Thanks for fixing this so fast!
            
            -Mike
            
            > On Apr 23, 2015, at 11:08 PM, Eric Wong <e@80x24.org> wrote:
            > 
            > "Mulvaney, Mike" <MMulvaney@bna.com> wrote:
            >> I think it would be reasonable to fix this for Rack 1.6+.  It won't
            >> cause any problems for Rack 1.5 users, right?  The environment
            >> variable gets set and then ignored, so the app would behave exactly
            >> the same way.  If they want to use the new cleanup code, they can
            >> upgrade rack.
            > 
            > Right, this only affects 1.6 users.  1.5 users will need to upgrade for
            > this.

            message raw reply parent threadlink

possible errors reading mailing list archives
- by Eric Wong @ 04/07 23:22 UTC - next/prev

If you hit any errors or truncated/corrupted responses when reading ML
archives at http://bogomips.org/unicorn-public/ it's probably because of
a bug in the new rack.hijack-based proxy in front of the prefork Apache2
instance hosting.

Drop me (or this list) a plain-text mail with the URL(s) and any info
about your client/connection that's broken for you

Previously, it was yahns using a synchronous (Rack, no-hijack) proxy
from yahns in the extras/proxy_pass.rb file[2]

before:
  yahns:extras/proxy_pass.rb -> varnish -> mpm_prefork+mod_perl

after:
  yahns:lib/yahns/proxy_pass.rb -> varnish -> mpm_prefork+mod_perl

yahns mailing list archives with all the relevant commits are here:
http://yhbt.net/yahns-public/

In case the HTTP portion of the archives get hosed, archives of the
mailing lists are still git clonable with ssoma[1] (or just using
"git clone")

	git://yhbt.net/yahns-public
	git://bogomips.org/unicorn-public

In case the server is gets completely hosed by the yahns proxy_pass
changes, archives are still readable at:

	https://www.mail-archive.com/yahns-public@yhbt.net/
	https://www.mail-archive.com/unicorn-public@bogomips.org/

Finally, in case you haven't realized by now; unicorn has always been a
rip-off of Apache(1|2) prefork design.  The major difference is the
marketing of unicorn always focused on the shortcomings of the design :>

So any fully-buffering reverse proxy such as nginx or yahns/proxy_pass
which protects one preforking server implementation from slow clients
will protect another...

[1] http://ssoma.public-inbox.org/
[2] git clone git://yhbt.net/yahns

message raw reply threadlink

[PATCH] favor more string literals for cold call sites
- by Eric Wong @ 04/07 07:56 UTC - next/prev

Literal regexps cost over 450 bytes of memory per-site and
unnecessary use of them costs memory in places where raw execution
speed does not matter.  Nowadays, we can rely on String#end_with?
(introduced in 1.8.7) for improved readability, too.

more... raw reply threadlink

$USER and $HOME shell variables not set
- by Russell Jennings @ 03/27 14:32 UTC - next/prev

Hello,

I am running into some issues with these variables being set - since I am spawning a script from a unicorn worker (via a rails controller) I figured I’d ask here. 

Here is the stackoverflow with the full background:
http://stackoverflow.com/questions/29233181/why-is-envhome-nil-in-my-rake-task

in short: does unicorn have anything to do with $HOME or $USER not being defined? From what I can tell, that its unicorn is the only thing thats different versus running the same ruby via a rails console (which does indeed set those shell variables correctly)

in no mans land, so any hep or insight would be greatly appreciated. 

Thanks,
Russell

message raw reply threadlink

  Re: $USER and $HOME shell variables not set
  - by Eric Wong @ 03/27 18:34 UTC - next/prev

  Russell Jennings <violentpurr@gmail.com> wrote:
  > Hello,
  > 
  > I am running into some issues with these variables being set - since I
  > am spawning a script from a unicorn worker (via a rails controller) I
  > figured I’d ask here. 
  > 
  > Here is the stackoverflow with the full background:
  > http://stackoverflow.com/questions/29233181/why-is-envhome-nil-in-my-rake-task
  > 
  > in short: does unicorn have anything to do with $HOME or $USER not
  > being defined?
  
  Nope, unicorn itself does not change these variables.  We only set
  UNICORN_FD (for SIGUSR2 upgrades), PWD (if working_directory is used).
  
  Your init system may change users and clobber these options via
  sudo/su/env and similar wrappers, so I think it has to do with how
  you're starting unicorn.  If you're using sudo anywhere, the env_*
  options from the sudoers files will also affect which envs get
  clobbered/preserved/added.
  
  > From what I can tell, that its unicorn is the only
  > thing thats different versus running the same ruby via a rails console
  > (which does indeed set those shell variables correctly)
  > 
  > in no mans land, so any hep or insight would be greatly appreciated. 
  
  Can you add something to log the contents of ENV.inspect to
  a log file.  Perhaps something like:
  
  	Rails.logger.debug("env: #{ENV.inspect}")
  
  It would also be helpful to show the snippet of code from where you're
  running Rake in case you're accidentally setting an option wrong.
  
  
  Under Linux, you can also inspect the original environment of any running
  process from /proc/$PID/environ  In most cases/kernel versions, it won't
  keep up with env changes once a process is running.
  I use tr to replace '\0' with '\n' (newline) to help with readability
  
  	tr '\0' '\n' </proc/$PID/environ

  message raw reply parent threadlink

  Re: nginx reverse proxy getting ECONNRESET
  - by Eric Wong @ 03/25 10:12 UTC - next/prev

  Michael Fischer <mfischer@zendesk.com> wrote:
  > On Tue, Mar 24, 2015 at 11:55 PM, Eric Wong <e@80x24.org> wrote:
  > 
  > > Actually, are you getting 502 errors returned from nginx in this case?
  > > That would not be harmless.  I suggest ensuring rack.input is
  > > fully-drained if that is the case (perhaps using PrereadInput).
  > 
  > No, they're all 200 responses with a zero-length body size.  It's the
  > first time I'd ever seen such a combination of symptoms.
  
  OK, thanks for the update.
  
  I was wondering if including a Unicorn::PostreadInput middleware should
  be introduced to quiet your logs.  It should have the same effect as
  PrereadInput, but should provide better performance in the common case
  and also be compatible with "rewindable_input false" users.
  
  class Unicorn::PostreadInput
    def initialize(app)
      @app = app
    end
  
    def call(env)
      input = env["rack.input"] # save it here, in case the app reassigns it
      @app.call(env)
    ensure
      # Ensure the HTTP request is entirely read off the socket even
      # if the app aborts early.  This should prevent nginx from
      # complaining about ECONNRESET errors.
      unless env["rack.hijack_io"]
        buf = ''
        true while input.read(16384, buf)
        buf.clear
      end
    end
  end
  
  (totally untested)
  
  "Postread" doesn't sound quite right, though...

  message raw reply parent threadlink

  Re: nginx reverse proxy getting ECONNRESET
  - by Gabe Martin-Dempesy @ 04/08 16:22 UTC - next/prev

  Follow up on the resolution.
  
  Data was being left in the socket, although it wasn’t immediately obvious why. The affected end point received gzipped POST bodies, and would process this somewhat like this:
  
      uncompressed_body = StringIO.new(Zlib::GzipReader.new(request.body).read)
      process(uncompressed_body)
  
  At the end of each request, all of the uncompressed data had been consumed and `uncompressed_body.eof?` would always be true. However, GzipReader#close wasn’t explicitly called, causing anywhere between 1 and 7 trailing bytes of the 8 byte gzip footer to remain unread in request.body (rack.input) in a small portion of requests. Rewriting this to explicitly close the GzipReader forces it to read and validate the footer, and leaves us with a completely consumed request.body.
  
  Thanks for your help identifying the root cause.

  message raw reply threadlink


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