Question: How to limit size of log & error files
- by Dowd, Stephen @ 2015-07-24 13:54 UTC - next

I'd like to control the size and on disk layout of the unicorn error and output logs.   Basically I want ruby Logger like functionality where I can specify a fixed # of rolling logs each of which is limited to # mb in size.   Not sure how to do this in unicorn.rb.  

My unicorn.conf file has basically the defaults, with the exception of:

Stderr_path "/log/unicorn/stderr.log"
Stdout_path "/log/unicorn/stdout.log"


These files will grow to the point where the disk becomes full at which point we begin to see failures.   


Thanks in advance...

Steve

message raw reply threadlink

  Re: Question: How to limit size of log & error files
  - by Ben Lovell @ 2015-07-24 14:05 UTC - next/prev

  On 24 July 2015 at 14:54, Dowd, Stephen <stephen.dowd@emc.com> wrote:
  
  > <I'd like to control the size and on disk layout of the unicorn error ...>
  
  It's right there in the docs:
  http://unicorn.bogomips.org/examples/logrotate.conf
  
  Cheers,
  Ben

  message raw reply parent threadlink

  Re: Question: How to limit size of log & error files
  - by Hleb Valoshka @ 2015-07-24 14:28 UTC - next/prev

  On 7/24/15, Dowd, Stephen <stephen.dowd@emc.com> wrote:
  > I'd like to control the size and on disk layout of the unicorn error and
  > output logs.   Basically I want ruby Logger like functionality where I can
  > specify a fixed # of rolling logs each of which is limited to # mb in size.
  >  Not sure how to do this in unicorn.rb.
  >
  > My unicorn.conf file has basically the defaults, with the exception of:
  >
  > Stderr_path "/log/unicorn/stderr.log"
  > Stdout_path "/log/unicorn/stdout.log"
  
  Create 2 FIFO and forward to syslog.

  message raw reply parent threadlink

  Re: Question: How to limit size of log & error files
  - by Eric Wong @ 2015-07-24 17:13 UTC - next/prev

  "Dowd, Stephen" <stephen.dowd@emc.com> wrote:
  > I'd like to control the size and on disk layout of the unicorn error
  > and output logs.   Basically I want ruby Logger like functionality
  > where I can specify a fixed # of rolling logs each of which is limited
  > to # mb in size.   Not sure how to do this in unicorn.rb. 
  
  You can also use the "logger" directive to avoid using the default
  Logger (which goes to $stderr) instead:
  
  http://unicorn.bogomips.org/Unicorn/Configurator.html#method-i-logger
  
  You'll also need to reconfigure Rack::CommonLogger and/or whatever
  logger your framework (e.g. Rails/Sinatra) uses.
  
  In modern versions of Ruby, the Logger class also seems multi-process
  aware when doing its internal logrotation.
  
  There is also SyslogLogger RubyGem which provides a Logger interface but
  goes directly to syslog.
  
  > My unicorn.conf file has basically the defaults, with the exception of:
  > 
  > Stderr_path "/log/unicorn/stderr.log"
  > Stdout_path "/log/unicorn/stdout.log"
   
  > These files will grow to the point where the disk becomes full at
  > which point we begin to see failures.   
  
  I prefer to log to files and use logrotate using a config as in
  http://unicorn.bogomips.org/examples/logrotate.conf as Ben pointed out.
  
  But you can also point those to FIFO + chronolog as Hleb pointed out,
  too.  That might be a little slower because of the context switches
  and synchronous wakeups.

  message raw reply parent threadlink

[PATCH] doc: remove references to old servers
- by Eric Wong @ 2015-07-15 22:05 UTC - next/prev

They'll continue to be maintained, but we're no longer advertising
them.  Also, favor lowercase "unicorn" while we're at it since that
matches the executable and gem name to avoid unnecessary escaping
for RDoc.

more... raw reply threadlink

[PATCH] configurator: document net.core.somaxconn sysctl dependency
- by Eric Wong @ 2015-07-15 21:38 UTC - next/prev

Linux users are effectively capped to 128 on stock installations
and may wonder why connections get rejected with overloaded apps
sooner rather than later.

more... raw reply threadlink

[PATCH] test_exec: disable systemd inheritance test
- by Eric Wong @ 2015-07-08 03:03 UTC - next/prev

Turns out ruby does have trouble emulating systemd, for now:

[ruby-core:69895] https://bugs.ruby-lang.org/issues/11336

When we re-enable this test, we'll only enable it for fixed Rubies.
The actual socket inheritance functionality works in any version of
Ruby, of course, it's just that emulating systemd won't work until
ruby-core fixes mainline Ruby.

more... raw reply threadlink

[PATCH] test/unit/test_response.rb: compatibility with older test-unit
- by Eric Wong @ 2015-07-05 00:31 UTC - next/prev

assert_predicate really isn't that useful even if it seems
preferred in another project I work on.  Avoid having folks
download the latest test-unit if they're on an old version of
Ruby (e.g. 1.9.3) which bundled it.

more... raw reply threadlink

Unicorn returns blank page after no use
- by Farjad Adamjee @ 2015-07-01 16:08 UTC - next/prev

Hello,

I am not sure if this is the correct place for this, I have googled 
around to see if anyone else has encountered such an issue, but I did 
not find anything.

I am having this issue where after a period of time of no use (on beta 
[production] environment), maybe 12 hours or so, the unicorn process 
sleeps. When I go and re-request the page, it returns blank.

I am using Apache proxy to Unicorn.

My unicorn.stderr.log states:
I, [2015-07-01T03:07:05.168511 #13258]  INFO -- : master done reopening logs
I, [2015-07-01T03:07:05.232546 #16222]  INFO -- : worker=2 done 
reopening logs
I, [2015-07-01T03:07:05.239934 #13308]  INFO -- : worker=0 done 
reopening logs
I, [2015-07-01T03:07:05.307616 #13311]  INFO -- : worker=1 done 
reopening logs


When I request the page again, it loads fine. It is only during the 
process of "reopening logs" when it returns a blank page.

My unicorn.rb file:

worker_processes 3

# Load app into the master before forking workers
# for super-fast worker spawn times
preload_app true

# Listen on
listen "127.0.0.1:8550", :backlog => 1024

# Restart any workers that haven't responded in 180 seconds
timeout 600

# PID for the Unicorn master
pid "/var/www/r/shared/pids/unicorn.pid"

# Unicorn Log paths
stderr_path "/var/www/r/shared/log/unicorn.stderr.log"
stdout_path "/var/www/r/shared/log/unicorn.stdout.log"

before_fork do |server, worker|
   ##
   # When sent a USR2, Unicorn will suffix its pidfile with .oldbin and
   # immediately start loading up a new version of itself (loaded with a new
   # version of our app). When this new Unicorn is completely loaded
   # it will begin spawning workers. The first worker spawned will check to
   # see if an .oldbin pidfile exists. If so, this means we've just 
booted up
   # a new Unicorn and need to tell the old one that it can now die. To 
do so
   # we send it a QUIT.
   #
   # Using this method we get 0 downtime deploys.
   defined?(ActiveRecord::Base) and 
ActiveRecord::Base.connection.disconnect!
   defined?(OathKeeper) and OathKeeper.disconnect!

   old_pid = '/var/www/r/shared/pids/unicorn.pid.oldbin'
   if File.exists?(old_pid) && server.pid != old_pid
     begin
       Process.kill("QUIT", File.read(old_pid).to_i)
     rescue Errno::ENOENT, Errno::ESRCH
       # someone else did our job for us
     end
   end
end

after_fork do |server, worker|
   ##
   #  # Unicorn master loads the app then forks off workers - because of 
the way
   #    # Unix forking works, we need to make sure we aren't using any 
of the parent's
   #      # sockets, e.g. db connection
   #
   defined?(ActiveRecord::Base) and ActiveRecord::Base.establish_connection
   defined?(OathKeeper) and OathKeeper.reconnect
end

Any help would be appreciated!
Thank you!

Farjad

more... raw reply threadlink

  Re: Unicorn returns blank page after no use
  - by Eric Wong @ 2015-07-01 17:30 UTC - next/prev

  Farjad Adamjee <fadamjee@vailsys.com> wrote:
  > Hello,
  > 
  > I am not sure if this is the correct place for this, I have googled
  > around to see if anyone else has encountered such an issue, but I
  > did not find anything.
  
  This is the correct place :)  Plain-text email is the only way I
  handle support for ease-of-archival and distribution.
  
  > I am having this issue where after a period of time of no use (on
  > beta [production] environment), maybe 12 hours or so, the unicorn
  > process sleeps. When I go and re-request the page, it returns blank.
  
  This sounds like a database (or any other persistent connection
  backend) connection expiring due to an idle timeout.
  
  This could also be a firewall/router timeout problem between the
  server running unicorn and the database host.
  
  Tony experienced this last year:
  http://bogomips.org/unicorn-public/m/CAKM1sPNRsES6H6ByK6bO9Djwa8WvYV6HJ-rEaHopRUYBVFfuhg@mail.gmail.com
  
  You can confirm by running lsof on a worker processes to look for
  open sockets.  In case the connection loss isn't noticed by the
  OS, use strace (or any other similar syscall tracer for your OS)
  instead and watch connection activity.
  
  With strace (or similar) knock yourself down to one worker
  process via SIGTTOU to the master to ensure you're always tracing
  the correct one.
  
  > I am using Apache proxy to Unicorn.
  
  By the way, this is not recommended for slow clients.
  nginx (Open Source edition) is currently the only supported proxy.
  
  >   # Using this method we get 0 downtime deploys.
  >   defined?(ActiveRecord::Base) and
  > ActiveRecord::Base.connection.disconnect!
  >   defined?(OathKeeper) and OathKeeper.disconnect!
  
  I suggest disabling any idle timeout you might have, enabling TCP
  keepalive and enabling reconnects (see AR and your database driver
  documentation).  Worst case (firewall/router problem you can't
  fix via configuration), is to send a request to unicorn every
  few minutes/hours to keep things going.
  
  Perhaps OathKeeper has the same problem, too...
  I've never heard of it until now.

  message raw reply parent threadlink

[PATCH 0/3] reflect changes to Rack::Utils::HTTP_STATUS_CODES
- by Eric Wong @ 2015-06-30 22:51 UTC - next/prev

A user privately reported (to unicorn@bogomips.org) that they wanted
status text reflected in their responses for an HTTP status code not
included with Rack::Utils::HTTP_STATUS_CODES.

They tried to modify Rack::Utils::HTTP_STATUS_CODES hash directly in
their app, but unicorn loads before their app and already memoized the
status codes internally in the CODES hash to reduce GC pressure, thus
their change was never reflected.

With the first change, users can change Rack::Utils::HTTP_STATUS_CODES
as many times as they want (perhaps even based on time-of-day, weather,
server load, whatever) and the changes will be reflected
instantaneously in responses.

Of course, this slows unicorn down slightly due to increased GC
pressure, but I doubt anybody would notice in Real World usage.
In case they do, patch 2/3 will recover the lost performance
if they're using Ruby 2.2+

I figure anybody who cares about micro-benchmark performance with
unicorn would be using the latest Rubies anyways...

That user is Bcc:-ed for these patches, and can follow any public
discussion at: http://bogomips.org/unicorn-public/
(including the Atom feed at http://bogomips.org/unicorn-public/atom.xml )

* [PATCH 1/3] reflect changes in Rack::Utils::HTTP_STATUS_CODES
  introduces a performance regression

* [PATCH 2/3] reduce constants and optimize for Ruby 2.2
  recover lost performance from [PATCH 1/3] (on Ruby 2.2+),
  further regressions for 2.1+

* [PATCH 3/3] http_response: reduce size of multi-line header path
  bonus reduce code size for common cases, should

 lib/unicorn/http_request.rb  | 19 +++++++------------
 lib/unicorn/http_response.rb | 23 ++++++++++-------------
 test/unit/test_response.rb   | 20 ++++++++++++++++++++
 3 files changed, 37 insertions(+), 25 deletions(-)

message raw reply threadlink

  [PATCH 1/3] reflect changes in Rack::Utils::HTTP_STATUS_CODES
  - by Eric Wong @ 2015-06-30 22:51 UTC - next/prev

  Applications may want to alter the message associated with HTTP
  status codes in Rack::Utils::HTTP_STATUS_CODES.  Avoid memoizing
  status lines ahead-of-time
  
  Note: this introduces a minor performance regression, but ought to
  be unnoticeable unless you're running "Hello world"-type apps.

  more... raw reply parent threadlink

  [PATCH 2/3] reduce constants and optimize for Ruby 2.2
  - by Eric Wong @ 2015-06-30 22:51 UTC - next/prev

  Ruby (MRI) 2.1 optimizes allocations away on String#freeze with
  literal strings.
  
  Furthermore, Ruby 2.2 optimizes away literal string allocations
  when they are used as arguments to Hash#[] and Hash#[]=
  
  Thus we can avoid expensive constant lookups and cache overhead
  by taking advantage of advancements in Ruby.
  
  Since Ruby 2.2 has been out for 7 months, now; it ought to be safe
  to introduce minor performance regressions for folks using older
  Rubies (1.9.3+ remains supported) to benefit folks on the latest
  Ruby.
  
  This should recover the performance lost in the
  "reflect changes in Rack::Utils::HTTP_STATUS_CODES" change
  in synthetic benchmarks.

  more... raw reply parent threadlink

  [PATCH 3/3] http_response: reduce size of multi-line header path
  - by Eric Wong @ 2015-06-30 22:51 UTC - next/prev

  This should save over 100 bytes of bytecode overhead due to
  reduced method dispatch points.  The performance difference
  when this is actually hit could go either way depending on
  how String#<< and realloc(3) interact, but it's uncommon
  enough that nobody is expected to notice either way.

  more... raw reply parent threadlink

Re: [DRE-maint] unicorn: native systemd service
- by Eric Wong @ 2015-06-27 03:05 UTC - next/prev

Christos Trochalakis <yatiohi@ideopolis.gr> wrote:
> <On Thu, Jun 25, 2015 at 11:26:26PM +0000, Eric Wong wrote: > >With ...>

OK, I'll probably add LISTEN_FDS and LISTEN_PID support to unicorn
directly so the wrapper is unnecessary.

<snip>

> KillMode=mixed

I don't think KillMode=mixed is necessary, here.  systemd can send
SIGQUIT to workers.

<snip>

> TCP socket options are not applied by unicorn on inherited sockets (TCPSocket
> === sock is false). systemd socket files have support for most options now but
> we might want unicorn to `setsockopt` them as well. For example,
> 'DeferAcceptSec', 'KeepAliveIntervalSec', 'NoDelay' are supported since v216, so
> they are not available in jessie (v215).

They are now :)

http://bogomips.org/unicorn-public/m/1435373879-4299-1-git-send-email-e@80x24.org.txt

We don't have KeepAliveIntervalSec
(aka TCP_KEEPINTVL) since it's not-portable and probably over
Are you sure about that?

> socket activation is a really interesting setup, but personally I would not run
> it with a large application. Clients would have to wait for the new master to
> be up and running before a reply is returned, and that could take tenths of
> seconds. The USR2 rexec solves that problem since both old and new workers are
> accepting on the socket and we can kill the old ones when we are ready. In that
> case the PIDFile trick is handy to support zero downtime restarts with no
> latency.

Is it possible to make systemd fire up two unicorn masters?
That would be a nice feature to have with socket activation.

message raw reply parent threadlink

  [RFC] emulate sd_listen_fds for systemd support
  - by Eric Wong @ 2015-06-27 04:01 UTC - next/prev

  Unfortunately, testing this is tricky because FD=3
  (SD_LISTEN_FDS_START) tends to be grabbed by (MRI) Ruby 1.9.3
  and onwards for the internal self-pipe.
  
  So for now, I've manually tested this with a systemd installation
  
  Disclaimer: this is also my first experience using systemd

  more... raw reply parent threadlink

    Re: [RFC] emulate sd_listen_fds for systemd support
    - by Christos Trochalakis @ 2015-06-30 08:47 UTC - next/prev

    On Sat, Jun 27, 2015 at 04:01:36AM +0000, Eric Wong wrote:
    >Unfortunately, testing this is tricky because FD=3
    >(SD_LISTEN_FDS_START) tends to be grabbed by (MRI) Ruby 1.9.3
    >and onwards for the internal self-pipe.
    >
    >So for now, I've manually tested this with a systemd installation
    >
    >Disclaimer: this is also my first experience using systemd
    >
    
    I have also tested it and works as expected. Also, hardcoding
    SD_LISTEN_FDS_START seems like the best option. I 'd like to see that
    applied to master.

    message raw reply parent threadlink

      [PATCH v2] emulate sd_listen_fds for systemd support
      - by Eric Wong @ 2015-07-05 00:27 UTC - next/prev

      systemd socket emulation shares FDs across execve, just like
      the built-in SIGUSR2 upgrade process in unicorn.  Thus it is
      easy to support inheriting sockets from systemd.
      
      Tested-by: Christos Trochalakis <yatiohi@ideopolis.gr>

      more... raw reply parent threadlink

  Re: [DRE-maint] unicorn: native systemd service
  - by Christos Trochalakis @ 2015-06-30 09:20 UTC - next/prev

  On Sat, Jun 27, 2015 at 03:05:01AM +0000, Eric Wong wrote:
  > <Christos Trochalakis <yatiohi@ideopolis.gr> wrote: >> On ...>
  
  Perhaps there is a race here, if a worker receives SIGQUIT first, and the
  master respawns a new worker before receiving/handling its own SIGQUIT.
  This is definitely a longshot, and will probably never happen, but
  even then every process will eventually quit gracefully.
  
  > <<snip> > >> TCP socket options are not applied by unicorn ...>
  
  I added 'KeepAliveIntervalSec' by mistake. `KeepAlive`, a supported
  option by unicorn, is included in jessie (systemd v215). Either way with
  your last patch those options are enforced by unicorn.
  
  >
  >> socket activation is a really interesting setup, but personally I would not run
  >> it with a large application. Clients would have to wait for the new master to
  >> be up and running before a reply is returned, and that could take tenths of
  >> seconds. The USR2 rexec solves that problem since both old and new workers are
  >> accepting on the socket and we can kill the old ones when we are ready. In that
  >> case the PIDFile trick is handy to support zero downtime restarts with no
  >> latency.
  >
  >Is it possible to make systemd fire up two unicorn masters?
  >That would be a nice feature to have with socket activation.
  
  That would be great! I am a bit surprised that specifying multiple
  services ('Service=' option) is not supported.

  message raw reply parent threadlink

    Re: [DRE-maint] unicorn: native systemd service
    - by Eric Wong @ 2015-06-30 17:30 UTC - next/prev

    Christos Trochalakis <yatiohi@ideopolis.gr> wrote:
    > On Sat, Jun 27, 2015 at 03:05:01AM +0000, Eric Wong wrote:
    > >Christos Trochalakis <yatiohi@ideopolis.gr> wrote:
    > >>KillMode=mixed
    > >
    > >I don't think KillMode=mixed is necessary, here.  systemd can send
    > >SIGQUIT to workers.
    > >
    > 
    > Perhaps there is a race here, if a worker receives SIGQUIT first, and the
    > master respawns a new worker before receiving/handling its own SIGQUIT.
    > This is definitely a longshot, and will probably never happen, but
    > even then every process will eventually quit gracefully.
    
    Right. This race is possible, but workers will automatically die if
    they don't have a master.
    Easier just to kill the master, of course.
    
    > >Is it possible to make systemd fire up two unicorn masters?
    > >That would be a nice feature to have with socket activation.
    > 
    > That would be great! I am a bit surprised that specifying multiple
    > services ('Service=' option) is not supported.
    
    Can you get this feature added to systemd?

    message raw reply parent threadlink

      Re: [DRE-maint] unicorn: native systemd service
      - by Christos Trochalakis @ 2015-07-08 13:08 UTC - next/prev

      >Christos Trochalakis <yatiohi@ideopolis.gr> wrote:
      >> On Sat, Jun 27, 2015 at 03:05:01AM +0000, Eric Wong wrote:
      >> >Is it possible to make systemd fire up two unicorn masters?
      >> >That would be a nice feature to have with socket activation.
      >>
      >> That would be great! I am a bit surprised that specifying multiple
      >> services ('Service=' option) is not supported.
      
      Apparently I was wrong. I missed the 'Sockets=' option for Service units.
      
      You can specify a list of socket units to be inherited (if active) when
      the service is started. Note that this is not the reverse of Sockets'
      'Service=' option: the service is not auto-started when there is an
      incoming connnection on the relevant socket, you have to use 'Service='
      for socket activation.
      
      Here is a test config for 2 preforked unicorn masters using service
      templates (I am using the latest unicorn with the systemd patch):
      
      ==> /srv/uni/config.ru <==
      puts "initializing for 5sec"
      sleep 5
      
      app = proc do |env|
        [
          200,
          { 'Content-Type' => 'text/plain' },
          ["ppid:#{Process.ppid}\n"]
        ]
      end
      
      run app
      
      ==> /srv/uni/unicorn.conf.rb <==
      worker_processes 2
      working_directory "/srv/uni"
      
      # Keep in sync with uni.socket file
      listen 9000
      listen 9001
      
      ==> /etc/systemd/system/uni@.service <==
      [Unit]
      Description=Unicorn Server %i
      Wants=uni.socket
      After=uni.socket
      
      [Service]
      ExecStart=/usr/local/bin/unicorn -c /srv/uni/unicorn.conf.rb -d
      Sockets=uni.socket
      KillSignal=SIGQUIT
      
      [Install]
      WantedBy=multi-user.target
      
      ==> /etc/systemd/system/uni.socket <==
      [Unit]
      Description=Unicorn Sockets
      
      [Socket]
      ListenStream=0.0.0.0:9000
      ListenStream=0.0.0.0:9001
      Service=uni@1.service
      
      [Install]
      WantedBy=sockets.target
      
      ==> end <==
      
      systemctl daemon-reload
      systemctl enable uni.socket
      systemctl start uni.socket
      
      systemctl enable uni@1 uni@2 # Make them start at boot
      systemctl start uni@1 uni@2
      
      Now you can start and stop uni@1 and uni@2 with zero latency and without losing
      a connection. So we have a happy ending after all :)
      
      While searching systemd's mailing list, I found a thread discussing about a
      'Distribute=' option to sockets a few years back[0]. There is also a relevant
      item in systemd's TODO list.
      
      [0] http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/14242/focus=14255

      message raw reply parent threadlink

[PATCH] apply TCP socket options on inherited sockets
- by Eric Wong @ 2015-06-27 02:57 UTC - next/prev

TCP socket options are now set when inheriting existing sockets from
a parent process.  I'm fairly certain all the TCP setsockopt knobs
we use are idempotent and harmless to change.

If anything, the only directive I'd be uncomfortable changing is
shortening the listen(2) (aka :backlog) size, but we've always
changed that anyways since it also applies to UNIX sockets.

Note: removing a configuration knob in a unicorn config file can not
reset the value to the OS-provided default setting.  Inherited
sockets must use a new setting to override existing ones.
(or the socket needs to be closed and re-created in the process
 launcher before unicorn inherits it).

Noticed-by: Christos Trochalakis <yatiohi@ideopolis.gr>
  <20150626114129.GA25883@luke.ws.skroutz.gr>

more... raw reply threadlink

  TAN: Coquelicot
  - by Eric Wong @ 2015-06-30 23:19 UTC - next/prev

  Lunar <lunar@anargeek.net> wrote:
  > Rainbows! is used by Coquelicot:
  > https://coquelicot.potager.org/
  > 
  > The project needs some love, but I know about several installations that
  > are used on a daily basis.
  
  Interesting!  I'm honestly a bit disappointed it's not a generic Rack
  app and depends on certain server features, but the project seems mostly
  inline with my interests.
  
  But if I were to run it, I'd remove all CSS+images+JS and might
  contribute a patch to disable that all, too :)
  
  Anyways, subscribed to the mailing list :>

  message raw reply parent threadlink

    Re: TAN: Coquelicot
    - by Lunar @ 2015-07-01 11:54 UTC - next/prev

    Eric Wong:
    > Lunar <lunar@anargeek.net> wrote:
    > > Rainbows! is used by Coquelicot:
    > > https://coquelicot.potager.org/
    > > 
    > > The project needs some love, but I know about several installations that
    > > are used on a daily basis.
    > 
    > Interesting!  I'm honestly a bit disappointed it's not a generic Rack
    > app and depends on certain server features, but the project seems mostly
    > inline with my interests.
    
    In the very first versions, it was a generic Rack app. And then I
    discovered that the file that was transmitted was saved in clear before
    being given to the handler (where it would get encrypted)…
    Finding that Rainbows! could be made to process the incoming bytes
    directly really helped in fixing this issue.
    
    The choice of tying it to a single HTTP server is also a conscious
    decision to make it easy to install. On Debian, it only requires
    `apt-get install coquelicot` and then 3 lines in Apache configuration.
    
    > But if I were to run it, I'd remove all CSS+images+JS and might
    > contribute a patch to disable that all, too :)
    
    Why not. :)

    more... raw reply parent threadlink

  [ANN] unicorn 5.0.0.pre2 - another prerelease!
  - by Eric Wong @ 2015-07-06 21:41 UTC - next/prev

  There is a minor TCP socket options are now applied to inherited
  sockets, and we have native support for inheriting sockets from
  systemd (by emulating the sd_listen_fds(3) function).
  
  Dynamic changes in the application to Rack::Utils::HTTP_STATUS
  codes is now supported, so you can use your own custom status
  lines.
  
  Ruby 2.2 and later is now favored for performance.
  Optimizations by using constants which made sense in earlier
  versions of Ruby are gone: so users of old Ruby versions
  will see performance regressions.  Ruby 2.2 users should
  see the same or better performance, and we have less code
  as a result.
  
  * doc: update some invalid URLs
  * apply TCP socket options on inherited sockets
  * reflect changes in Rack::Utils::HTTP_STATUS_CODES
  * reduce constants and optimize for Ruby 2.2
  * http_response: reduce size of multi-line header path
  * emulate sd_listen_fds for systemd support
  * test/unit/test_response.rb: compatibility with older test-unit
  
  This also includes all changes in unicorn 5.0.0.pre1:
  
  http://bogomips.org/unicorn-public/m/20150615225652.GA16164@dcvr.yhbt.net.html

  more... 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