* [ANN] unicorn 5.5.1 - Rack HTTP server for fast clients and
@ 2019-05-06 6:50 4% Eric Wong
0 siblings, 0 replies; 3+ results
From: Eric Wong @ 2019-05-06 6:50 UTC (permalink / raw)
To: ruby-talk, unicorn-public; +Cc: Jeremy Evans, Stan Pitucha, Stephen Demjanenko
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.
Disclaimer:
Due to its ability to tolerate crashes and isolate clients, unicorn
is unfortunately known to prolong the existence of bugs in applications
and libraries which run on top of it.
* https://bogomips.org/unicorn/
* public list: unicorn-public@bogomips.org
* mail archives: https://bogomips.org/unicorn-public/
* git clone https://bogomips.org/unicorn.git
* https://bogomips.org/unicorn/NEWS.atom.xml
* nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn
This release fixes and works around issues from v5.5.0 (2019-03-04)
Stephen Demjanenko worked around a pipe resource accounting bug
present in old Linux kernels. Linux 3.x users from 3.16.57 and
on are unaffected. Linux 4.x users from 4.9 and on are
unaffected.
https://bogomips.org/unicorn-public/1556922018-24096-1-git-send-email-sdemjanenko@gmail.com/
Stan Pitucha reported a bug with the old `unicorn_rails' wrapper
(intended for Rails 2.x users) which was promptly fixed by
Jeremy Evans:
https://bogomips.org/unicorn-public/CAJ2_uEPifcv_ux4sX=t0C4zHTHGhqVfcLcSB2kTU3Rb_6pQ3nw@mail.gmail.com/
There's also some doc updates to warn users off `unicorn_rails';
the homepage is now energy-efficient for OLEDs and CRTs;
and I'm no longer advertising mailing list subscriptions
(because I hate centralization and mail archives are the priority)
Eric Wong (3):
doc: unicorn_rails: clarify that it is intended for rails <= 2.x
doc: stop advertising mailing list subscription
doc: switch homepage to dark216
Jeremy Evans (1):
unicorn_rails: fix regression with Rails >= 3.x in app build
Stephen Demjanenko (1):
Rescue failed pipe resizes due to permissions
havpbea: orngvat n qrnq ubefr hagvy gur fgvpx trgf fghpx va vg'f fxhyy
^ permalink raw reply [relevance 4%]
* Re: [PATCH] Rescue failed pipe resizes due to permissions
2019-05-03 22:20 6% [PATCH] Rescue failed pipe resizes due to permissions sdemjanenko
@ 2019-05-03 22:53 7% ` Eric Wong
0 siblings, 0 replies; 3+ results
From: Eric Wong @ 2019-05-03 22:53 UTC (permalink / raw)
To: Stephen Demjanenko; +Cc: unicorn-public
sdemjanenko@gmail.com wrote:
Thanks, patch looks good; though I'd like to confirm
some things below for the sake of documentation.
> The `EPERM` error gets raised by the Linux kernel if:
> ```
> (too_many_pipe_buffers_hard(pipe->user) ||
> too_many_pipe_buffers_soft(pipe->user)) &&
> !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)
> ```
Which kernel are you running?
Modern kernels prefix that condition with:
if (nr_pages > pipe->buffers &&
Scanning kernel changes with `git log -p -L:pipe_set_size:fs/pipe.c',
I see that check was added in b0b91d18e2e97b741b294af9333824ecc3fadfd8
("pipe: fix limit checking in pipe_set_size()")
which was fixed in Linux v4.9+ and v3.16.57+
https://80x24.org/mirrors/linux.git/commit?id=b0b91d18e2e97b741b294af9333824ecc3fadfd8
https://lore.kernel.org/lkml/?q=s%3A%22fix+limit+checking+in+pipe_set_size%22
> Given that the resize is not strictly necessary Unicorn should
> rescue the error and continue booting.
Agreed. Applied, tested and pushed to master as
commit 5c613c6ea98541df587193e861364c858a8a0abd
Thanks!
Will tag and release v5.5.1 in a day or two.
^ permalink raw reply [relevance 7%]
* [PATCH] Rescue failed pipe resizes due to permissions
@ 2019-05-03 22:20 6% sdemjanenko
2019-05-03 22:53 7% ` Eric Wong
0 siblings, 1 reply; 3+ results
From: sdemjanenko @ 2019-05-03 22:20 UTC (permalink / raw)
To: unicorn-public; +Cc: Stephen Demjanenko
From: Stephen Demjanenko <sdemjanenko@gmail.com>
When running: ```
require 'kgio'
require 'raindrops'
F_SETPIPE_SZ = 1031 if RUBY_PLATFORM =~ /linux/
Kgio::Pipe.new.each do |io|
io.close_on_exec = true
if defined?(F_SETPIPE_SZ)
begin
puts "setting"
io.fcntl(F_SETPIPE_SZ, Raindrops::PAGE_SIZE)
rescue Errno::EINVAL
puts "rescued"
rescue => e
puts ["FAILED HARD", e].inspect
end
end
end
```
on a few servers to test some Unicorn boot failures I saw:
```
["FAILED HARD", #<Errno::EPERM: Operation not permitted>]
```
The `EPERM` error gets raised by the Linux kernel if:
```
(too_many_pipe_buffers_hard(pipe->user) ||
too_many_pipe_buffers_soft(pipe->user)) &&
!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)
```
Given that the resize is not strictly necessary Unicorn should
rescue the error and continue booting.
---
lib/unicorn.rb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/unicorn.rb b/lib/unicorn.rb
index 5f2134d..dd5dff4 100644
--- a/lib/unicorn.rb
+++ b/lib/unicorn.rb
@@ -123,6 +123,9 @@ def self.pipe # :nodoc:
io.fcntl(F_SETPIPE_SZ, Raindrops::PAGE_SIZE)
rescue Errno::EINVAL
# old kernel
+ rescue Errno::EPERM
+ # resizes fail if Linux is close to the pipe limit for the user
+ # or if the user does not have permissions to resize
end
end
end
--
2.7.4
^ permalink raw reply related [relevance 6%]
Results 1-3 of 3 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2019-05-03 22:20 6% [PATCH] Rescue failed pipe resizes due to permissions sdemjanenko
2019-05-03 22:53 7% ` Eric Wong
2019-05-06 6:50 4% [ANN] unicorn 5.5.1 - Rack HTTP server for fast clients and Eric Wong
Code repositories for project(s) associated with this public inbox
https://yhbt.net/unicorn.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).