[PATCH] http: use rb_hash_clear in Ruby 2.0+
- by Eric Wong @ 05/29 06:03 UTC - next

Calling the function directly avoids the overhead of Ruby method
table lookup and global method cache.  The only downside is this is
now hidden from tracers and cannot be overridden from Ruby, but I
doubt anybody cares about that.

more... raw reply threadlink

[PATCH] ISSUES: discourage HTML mail strongly, welcome nyms
- by Eric Wong @ 05/20 23:21 UTC - next/prev

HTML email is too likely to be lost, so more strongly discourage it.
While we're at it, make it clear we allow anonymous and pseudonymous
contributions, unlike many projects nowadays.

more... raw reply threadlink

SIGWINCH ignored...
- by Dan Moore @ 05/19 14:02 UTC - next/prev

I’m interested in the SIGWINCH signal and specifically the message that is posted to the console at an INFO level instead of DEBUG level: https://github.com/ddollar/foreman/issues/557 “INFO – : SIGWINCH ignored because we’re not daemonized” I would like to request that this be moved to DEBUG level as it’s quite chatty when using tmux, foreman, and terminal. I apologize if this was already discussed, but I cannot seem to perform a full search on the email archives.

message raw reply threadlink

  Re: SIGWINCH ignored...
  - by Eric Wong @ 05/19 23:28 UTC - next/prev

  Don't send HTML parts, it is flagged as spam and nearly lost.
  
  Onto your question...
  
  Dan Moore <dan@vaporwa.re> wrote:
  > I’m interested in the SIGWINCH signal and specifically the message
  > that is posted to the console at an INFO level instead of DEBUG level:
  > https://github.com/ddollar/foreman/issues/557
  > “INFO – : SIGWINCH ignored because we’re not daemonized”
  
  I wrote this patch a while ago to a private bug reporter (via
  unicorn@bogomips.org) back in July 2013, but apparently it
  was forgotten:
  
  --- a/lib/unicorn/http_server.rb
  +++ b/lib/unicorn/http_server.rb
  @@ -294,13 +294,13 @@ class Unicorn::HttpServer
         when :USR2 # exec binary, stay alive in case something went wrong
           reexec
         when :WINCH
  -        if Unicorn::Configurator::RACKUP[:daemonized]
  +        if $stdin.tty?
  +          logger.info "SIGWINCH ignored because we're not daemonized"
  +        else
             respawn = false
             logger.info "gracefully stopping all workers"
             soft_kill_each_worker(:QUIT)
             self.worker_processes = 0
  -        else
  -          logger.info "SIGWINCH ignored because we're not daemonized"
           end
         when :TTIN
           respawn = true
  
  I don't recall it breaks anything, so perhaps it's a good change to make
  for unicorn 5.
  
  > I would like to request that
  > this be moved to DEBUG level as it’s quite chatty when using tmux,
  > foreman, and terminal.
  
  I don't think using DEBUG is a good idea to hack around a problem,
  but rather detecting whether stdin is a TTY as above is a better check.
  
  The archives are also mirrored to gmane.org and mail-archive.com,
  so they should be searchable from either of those.
  
  > I apologize if this was already discussed, but
  > I cannot seem to perform a full search on the email archives.
  
  The mailing list archives are cloneable via git:
    git clone --bare git://bogomips.org/unicorn-public/
  
  And the tree layout is described at:
    http://ssoma.public-inbox.org/ssoma_repository.txt
    (it's not meant to be cloned without --bare)
  
  You can currently use the ssoma command-line (at ssoma.public-inbox.org)
  tool to import the archives into a mbox/maildir and search using tools
  such as mairix/notmuch/etc...
  
  The existing HTML archives at http://bogomips.org/unicorn-public/ should
  be easily crawlable by search engines (no JS, frames, CSS or images),
  but a Xapian-based search might happen in the future (that would also
  help with maintaining stable IDs for read-only NNTP support).

  message raw reply parent threadlink

  Re: SIGWINCH ignored...
  - by Dan Moore @ 05/20 01:02 UTC - next/prev

  Thank you, that's perfect. +1 for unicorn 5 patch.

  message raw reply parent threadlink

    Re: SIGWINCH ignored...
    - by Eric Wong @ 05/20 23:11 UTC - next/prev

    Dan Moore <dan@vaporwa.re> wrote:
    > Thank you, that's perfect. +1 for unicorn 5 patch.
    
    Thanks for the confirmation, pushed as the following commit:
    
    commit a6077391bb62d0b13016084b0eea36b987afe8f0
    Author: Eric Wong <e@80x24.org>
    Date:   Wed May 20 22:15:48 2015 +0000
    
        process SIGWINCH unless stdin is a TTY
        
        Some process managers such as foreman and daemontools rely on
        unicorn not daemonizing, but we still want to be able to process
        SIGWINCH in that case.
        
        stdout and stderr may be redirected to a pipe (for cronolog or
        similar process), so those are less likely to be attached to a TTY
        than stdin.  This also allows users to process SIGWINCH when running
        inside a regular terminal if they redirect stdin to /dev/null.
        
        Reported-by: Dan Moore <dan@vaporwa.re>
        References: <etPan.555b4293.5b47a5b7.e617@danbookpro>
        	<20150519232858.GA23515@dcvr.yhbt.net>

    message raw reply parent threadlink

[PATCH] FAQ: add note about ECONNRESET errors from bodies
- by Eric Wong @ 05/18 21:34 UTC - next/prev

Thanks to Michael Fischer and Gabe Martin-Dempesy for bringing this
to light on the mailing list.

Ref: <CABHxtY7Sn5yaiR5a3gDk1G4XySE+UtfuqUTcOSdmwneXLD5rcg@mail.gmail.com>
Ref: <FC91211E-FD32-432C-92FC-0318714C2170@zendesk.com>

Cc: Michael Fischer <mfischer@zendesk.com>
Cc: Gabe Martin-Dempesy <gabe@zendesk.com>

more... raw reply threadlink

[PATCH 0/2] no avoiding rack.hijack anymore
- by Eric Wong @ 05/16 21:30 UTC - next/prev

I'm not sure if it makes sense to use rack.hijack with a prefork server
like unicorn which only works behind nginx, but maybe somebody does...

Eric Wong (2):
      http_request: support rack.hijack by default
      avoid extra allocation for hijack proc creation

 lib/unicorn/http_request.rb | 40 ++++++++++++++++------------------------
 1 file changed, 16 insertions(+), 24 deletions(-)

message raw reply threadlink

  [PATCH 1/2] http_request: support rack.hijack by default
  - by Eric Wong @ 05/16 21:30 UTC - next/prev

  Rack 1.4 and earlier will soon die out, so avoid having extra code
  
  The only minor overhead is assigning two hash slots and
  the extra hash checks when running ancient versions of Rack,
  so it is unlikely anybody cares about that overhead with Rack 1.5
  and later.

  more... raw reply parent threadlink

    [PATCH] http_response: avoid special-casing for Rack < 1.5
    - by Eric Wong @ 05/19 20:01 UTC - next/prev

    Rack 1.4 and earlier will soon die out, so avoid having extra,
    overengineered code and method dispatch to silently drop support
    for mis-hijacking with old Rack versions.
    
    This will cause improperly hijacked responses in all versions of
    Rack to fail, but allows properly hijacked responses to work
    regardless of Rack version.
    
    Followup-to: commit fdf09e562733f9509d275cb13c1c1a04e579a68a
    ("http_request: support rack.hijack by default")

    more... raw reply parent threadlink

  [PATCH 2/2] avoid extra allocation for hijack proc creation
  - by Eric Wong @ 05/16 21:30 UTC - next/prev

  proc creation is expensive, so merely use a 48-byte generic ivar
  hash slot for @socket instead.

  more... raw reply parent threadlink

[PATCH] favor kgio_wait_readable for single FD over select
- by Eric Wong @ 05/07 22:16 UTC - next/prev

kgio_wait_readable is superior for single FDs in that it may use the
ppoll syscall on Linux via Ruby, making it immune to the slowdown
high FDs with select() and the array allocations enforced by the
Ruby wrapper interface.

Note: IO#wait in the io/wait stdlib has the same effect, but as of
2.2 still needlessly checks the FIONREAD ioctl.  So avoid needing to
force a new require on users which also incur shared object loading
costs.  The longer term plan is to rely entirely on Ruby IO
primitives entirely and drop kgio, but that won't happen until we
can depend on Ruby 2.3 for exception-free accept_nonblock
(which will be released December 2015).

more... raw reply threadlink

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

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 @ 05/03 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 @ 05/03 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

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

[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


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