* [PATCH] doc: s/bogomips.org/yhbt.net/g
2020-01-14 7:46 10% [PATCH] doc: s/bogomips.org/yhbt.net/g Eric Wong
@ 2020-01-14 7:46 10% ` Eric Wong
0 siblings, 0 replies; 27+ results
From: Eric Wong @ 2020-01-14 7:46 UTC (permalink / raw)
To: unicorn-public
bogomips.org is due to expire, soon, and I'm not willing to pay
extortionist fees to Ethos Capital/PIR/ICANN to keep a .org. So
it's at yhbt.net, for now, but it will change again to
whatever's affordable... Identity is overrated.
Tor users can use .onions and kick ICANN to the curb:
torsocks w3m http://unicorn.ou63pmih66umazou.onion/
torsocks git clone http://ou63pmih66umazou.onion/unicorn.git/
torsocks w3m http://ou63pmih66umazou.onion/unicorn-public/
While we're at it, `s/news.gmane.org/news.gmane.io/g', too.
(but I suspect that'll need to be resynched since our mail
"List-Id:" header is changing).
---
.olddoc.yml | 19 ++++++++++++-------
Documentation/unicorn.1 | 8 ++++----
Documentation/unicorn_rails.1 | 8 ++++----
FAQ | 2 +-
GNUmakefile | 4 ++--
HACKING | 2 +-
ISSUES | 24 ++++++++++++------------
KNOWN_ISSUES | 4 ++--
Links | 10 +++++-----
README | 12 ++++++------
SIGNALS | 2 +-
Sandbox | 4 ++--
archive/slrnpull.conf | 2 +-
examples/big_app_gc.rb | 2 +-
examples/logrotate.conf | 4 ++--
examples/nginx.conf | 2 +-
examples/unicorn.conf.minimal.rb | 4 ++--
examples/unicorn.conf.rb | 4 ++--
ext/unicorn_http/unicorn_http.rl | 2 +-
lib/unicorn.rb | 2 +-
lib/unicorn/configurator.rb | 6 +++---
lib/unicorn/http_server.rb | 2 +-
lib/unicorn/oob_gc.rb | 4 ++--
unicorn.gemspec | 4 ++--
24 files changed, 71 insertions(+), 66 deletions(-)
diff --git a/.olddoc.yml b/.olddoc.yml
index d2d340f..0609bdb 100644
--- a/.olddoc.yml
+++ b/.olddoc.yml
@@ -1,8 +1,9 @@
---
-cgit_url: https://bogomips.org/unicorn.git
-git_url: https://bogomips.org/unicorn.git
-rdoc_url: https://bogomips.org/unicorn/
-ml_url: https://bogomips.org/unicorn-public/
+cgit_url: https://yhbt.net/unicorn.git
+rdoc_url: https://yhbt.net/unicorn/
+ml_url:
+- https://yhbt.net/unicorn-public/
+- http://ou63pmih66umazou.onion/unicorn-public/
merge_html:
unicorn_1: Documentation/unicorn.1.html
unicorn_rails_1: Documentation/unicorn_rails.1.html
@@ -11,7 +12,11 @@ noindex:
- LATEST
- TODO
- unicorn_rails_1
-public_email: unicorn-public@bogomips.org
+public_email: unicorn-public@yhbt.net
nntp_url:
- - nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn
- - nntp://news.gmane.org/gmane.comp.lang.ruby.unicorn.general
+- nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn
+- nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.unicorn
+- nntp://news.gmane.io/gmane.comp.lang.ruby.unicorn.general
+source_code:
+- git clone https://yhbt.net/unicorn.git
+- torsocks git clone http://ou63pmih66umazou.onion/unicorn.git
diff --git a/Documentation/unicorn.1 b/Documentation/unicorn.1
index 3f8cb96..d76d40f 100644
--- a/Documentation/unicorn.1
+++ b/Documentation/unicorn.1
@@ -154,7 +154,7 @@ TTIN \- increment the number of worker processes by one
.IP \[bu] 2
TTOU \- decrement the number of worker processes by one
.PP
-See the SIGNALS (https://bogomips.org/unicorn/SIGNALS.html) document for
+See the SIGNALS (https://yhbt.net/unicorn/SIGNALS.html) document for
full description of all signals used by Unicorn.
.SH RACK ENVIRONMENT
.PP
@@ -204,11 +204,11 @@ the unicorn config file.
\f[I]Rack::Builder\f[] ri/RDoc
.IP \[bu] 2
\f[I]Unicorn::Configurator\f[] ri/RDoc
-.UR https://bogomips.org/unicorn/Unicorn/Configurator.html
+.UR https://yhbt.net/unicorn/Unicorn/Configurator.html
.UE
.IP \[bu] 2
unicorn RDoc
-.UR https://bogomips.org/unicorn/
+.UR https://yhbt.net/unicorn/
.UE
.IP \[bu] 2
Rack RDoc
@@ -219,4 +219,4 @@ Rackup HowTo
.UR https://github.com/rack/rack/wiki/(tutorial)-rackup-howto
.UE
.SH AUTHORS
-The Unicorn Community <unicorn-public@bogomips.org>.
+The Unicorn Community <unicorn-public@yhbt.net>.
diff --git a/Documentation/unicorn_rails.1 b/Documentation/unicorn_rails.1
index 71c80be..fec0a2a 100644
--- a/Documentation/unicorn_rails.1
+++ b/Documentation/unicorn_rails.1
@@ -180,7 +180,7 @@ TTIN \- increment the number of worker processes by one
.IP \[bu] 2
TTOU \- decrement the number of worker processes by one
.PP
-See the SIGNALS (https://bogomips.org/unicorn/SIGNALS.html) document for
+See the SIGNALS (https://yhbt.net/unicorn/SIGNALS.html) document for
full description of all signals used by Unicorn.
.SH SEE ALSO
.IP \[bu] 2
@@ -189,11 +189,11 @@ unicorn(1)
\f[I]Rack::Builder\f[] ri/RDoc
.IP \[bu] 2
\f[I]Unicorn::Configurator\f[] ri/RDoc
-.UR https://bogomips.org/unicorn/Unicorn/Configurator.html
+.UR https://yhbt.net/unicorn/Unicorn/Configurator.html
.UE
.IP \[bu] 2
unicorn RDoc
-.UR https://bogomips.org/unicorn/
+.UR https://yhbt.net/unicorn/
.UE
.IP \[bu] 2
Rack RDoc
@@ -204,4 +204,4 @@ Rackup HowTo
.UR https://github.com/rack/rack/wiki/(tutorial)-rackup-howto
.UE
.SH AUTHORS
-The Unicorn Community <unicorn-public@bogomips.org>.
+The Unicorn Community <unicorn-public@yhbt.net>.
diff --git a/FAQ b/FAQ
index 4ae2034..018ca92 100644
--- a/FAQ
+++ b/FAQ
@@ -7,7 +7,7 @@ drained entirely by the application. This may happen when request
bodies are gzipped, as unicorn reads request body data lazily to avoid
overhead from bad requests.
-Ref: https://bogomips.org/unicorn-public/FC91211E-FD32-432C-92FC-0318714C2170@zendesk.com/
+Ref: https://yhbt.net/unicorn-public/FC91211E-FD32-432C-92FC-0318714C2170@zendesk.com/
=== Why aren't my Rails log files rotated when I use SIGUSR1?
diff --git a/GNUmakefile b/GNUmakefile
index 94c46ee..eac3473 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -193,13 +193,13 @@ doc: .document $(ext)/unicorn_http.c man html .olddoc.yml $(PLACEHOLDERS)
install -m644 $(man1_paths) doc/
tar cf - $$(git ls-files examples/) | (cd doc && tar xf -)
-# publishes docs to https://bogomips.org/unicorn/
+# publishes docs to https://yhbt.net/unicorn/
publish_doc:
-git set-file-times
$(MAKE) doc
$(MAKE) doc_gz
chmod 644 $$(find doc -type f)
- $(RSYNC) -av doc/ bogomips.org:/srv/bogomips/unicorn/
+ $(RSYNC) -av doc/ yhbt.net:/srv/yhbt/unicorn/
git ls-files | xargs touch
# Create gzip variants of the same timestamp as the original so nginx
diff --git a/HACKING b/HACKING
index be1bb85..976bf92 100644
--- a/HACKING
+++ b/HACKING
@@ -57,7 +57,7 @@ Please wrap documentation at 72 characters-per-line or less (long URLs
are exempt) so it is comfortably readable from terminals.
When referencing mailing list posts, use
-<tt>https://bogomips.org/unicorn-public/$MESSAGE_ID/</tt> if possible
+<tt>https://yhbt.net/unicorn-public/$MESSAGE_ID/</tt> if possible
since the Message-ID remains searchable even if a particular site
becomes unavailable.
diff --git a/ISSUES b/ISSUES
index 473da2f..d11dc56 100644
--- a/ISSUES
+++ b/ISSUES
@@ -1,9 +1,9 @@
= Issues
-mailto:unicorn-public@bogomips.org is the best place to report bugs,
+mailto:unicorn-public@yhbt.net is the best place to report bugs,
submit patches and/or obtain support after you have searched the
-{email archives}[https://bogomips.org/unicorn-public/] and
-{documentation}[https://bogomips.org/unicorn/].
+{email archives}[https://yhbt.net/unicorn-public/] and
+{documentation}[https://yhbt.net/unicorn/].
* No subscription will ever be required to email us
* Cc: all participants in a thread or commit, as subscription is optional
@@ -12,12 +12,12 @@ submit patches and/or obtain support after you have searched the
* Do not send HTML mail or images,
they hurt reader privacy and will be flagged as spam
* Anonymous and pseudonymous messages will ALWAYS be welcome
-* The email submission port (587) is enabled on the bogomips.org MX:
- https://bogomips.org/unicorn-public/20141004232241.GA23908@dcvr.yhbt.net/t/
+* The email submission port (587) is enabled on the yhbt.net MX:
+ https://yhbt.net/unicorn-public/20141004232241.GA23908@dcvr.yhbt.net/t/
We will never have a centralized or formal bug tracker. Instead we
can interoperate with any bug tracker which can Cc: us plain-text to
-mailto:unicorn-public@bogomips.org This includes the Debian BTS
+mailto:unicorn-public@yhbt.net This includes the Debian BTS
at https://bugs.debian.org/unicorn and possibly others.
If your issue is of a sensitive nature or you're just shy in public,
@@ -73,10 +73,10 @@ document distributed with git) on guidelines for patch submission.
== Contact Info
-* public: mailto:unicorn-public@bogomips.org
-* nntp://news.gmane.org/gmane.comp.lang.ruby.unicorn.general
+* public: mailto:unicorn-public@yhbt.net
+* nntp://news.gmane.io/gmane.comp.lang.ruby.unicorn.general
* nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn
-* https://bogomips.org/unicorn-public/
+* https://yhbt.net/unicorn-public/
* http://ou63pmih66umazou.onion/unicorn-public/
Mailing list subscription is optional, so Cc: all participants.
@@ -84,13 +84,13 @@ Mailing list subscription is optional, so Cc: all participants.
You can follow along via NNTP (read-only):
nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn
- nntp://news.gmane.org/gmane.comp.lang.ruby.unicorn.general
+ nntp://news.gmane.io/gmane.comp.lang.ruby.unicorn.general
Or Atom feeds:
- https://bogomips.org/unicorn-public/new.atom
+ https://yhbt.net/unicorn-public/new.atom
http://ou63pmih66umazou.onion/unicorn-public/new.atom
- The HTML archives at https://bogomips.org/unicorn-public/
+ The HTML archives at https://yhbt.net/unicorn-public/
also has links to per-thread Atom feeds and downloadable
mboxes.
diff --git a/KNOWN_ISSUES b/KNOWN_ISSUES
index ebd4822..0017f20 100644
--- a/KNOWN_ISSUES
+++ b/KNOWN_ISSUES
@@ -9,7 +9,7 @@ acceptable solution. Those issues are documented here.
handlers.
* Issues with FreeBSD jails can be worked around as documented by Tatsuya Ono:
- https://bogomips.org/unicorn-public/CAHBuKRj09FdxAgzsefJWotexw-7JYZGJMtgUp_dhjPz9VbKD6Q@mail.gmail.com/
+ https://yhbt.net/unicorn-public/CAHBuKRj09FdxAgzsefJWotexw-7JYZGJMtgUp_dhjPz9VbKD6Q@mail.gmail.com/
* PRNGs (pseudo-random number generators) loaded before forking
(e.g. "preload_app true") may need to have their internal state
@@ -60,7 +60,7 @@ acceptable solution. Those issues are documented here.
application to use Rails 2.3.2 and you have no other choice, then
you may edit your unicorn gemspec and remove the Rack dependency.
- ref: https://bogomips.org/unicorn-public/20091014221552.GA30624@dcvr.yhbt.net/
+ ref: https://yhbt.net/unicorn-public/20091014221552.GA30624@dcvr.yhbt.net/
Note: the workaround described in the article above only made
the issue more subtle and we didn't notice them immediately.
diff --git a/Links b/Links
index 10551a6..f81142d 100644
--- a/Links
+++ b/Links
@@ -2,7 +2,7 @@
If you're interested in unicorn, you may be interested in some of the projects
listed below. If you have any links to add/change/remove, please tell us at
-mailto:unicorn-public@bogomips.org!
+mailto:unicorn-public@yhbt.net!
== Disclaimer
@@ -23,10 +23,10 @@ or services behind them.
* {golden_brindle}[https://github.com/simonoff/golden_brindle] - tool to
manage multiple unicorn instances/applications on a single server
-* {raindrops}[https://bogomips.org/raindrops/] - real-time stats for
+* {raindrops}[https://yhbt.net/raindrops/] - real-time stats for
preforking Rack servers
-* {UnXF}[https://bogomips.org/unxf/] Un-X-Forward* the Rack environment,
+* {UnXF}[https://yhbt.net/unxf/] Un-X-Forward* the Rack environment,
useful since unicorn is designed to be deployed behind a reverse proxy.
=== unicorn is written to work with
@@ -52,7 +52,7 @@ or services behind them.
* {Mongrel}[https://rubygems.org/gems/mongrel] - the awesome webserver
unicorn is based on. A historical archive of the mongrel dev list
featuring early discussions of unicorn is available at:
- https://bogomips.org/mongrel-devel/
+ https://yhbt.net/mongrel-devel/
-* {david}[https://bogomips.org/david.git] - a tool to explain why you need
+* {david}[https://yhbt.net/david.git] - a tool to explain why you need
nginx in front of unicorn
diff --git a/README b/README
index 89467fc..0e95f48 100644
--- a/README
+++ b/README
@@ -80,12 +80,12 @@ You may install it via RubyGems on RubyGems.org:
You can get the latest source via git from the following locations
(these versions may not be stable):
- https://bogomips.org/unicorn.git
+ https://yhbt.net/unicorn.git
https://repo.or.cz/unicorn.git (mirror)
You may browse the code from the web:
-* https://bogomips.org/unicorn.git
+* https://yhbt.net/unicorn.git
* https://repo.or.cz/w/unicorn.git (gitweb)
See the HACKING guide on how to contribute and build prerelease gems
@@ -133,13 +133,13 @@ and libraries which run on top of it.
All feedback (bug reports, user/development dicussion, patches, pull
requests) go to the mailing list/newsgroup. See the ISSUES document for
-information on the {mailing list}[mailto:unicorn-public@bogomips.org].
+information on the {mailing list}[mailto:unicorn-public@yhbt.net].
-The mailing list is archived at https://bogomips.org/unicorn-public/
+The mailing list is archived at https://yhbt.net/unicorn-public/
Read-only NNTP access is available at:
nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn and
-nntp://news.gmane.org/gmane.comp.lang.ruby.unicorn.general
+nntp://news.gmane.io/gmane.comp.lang.ruby.unicorn.general
For the latest on unicorn releases, you may also finger us at
-unicorn@bogomips.org or check our NEWS page (and subscribe to our Atom
+unicorn@yhbt.net or check our NEWS page (and subscribe to our Atom
feed).
diff --git a/SIGNALS b/SIGNALS
index 1af851d..7321f2b 100644
--- a/SIGNALS
+++ b/SIGNALS
@@ -8,7 +8,7 @@ should be possible to easily share process management scripts between
Unicorn and nginx.
One example init script is distributed with unicorn:
-https://bogomips.org/unicorn/examples/init.sh
+https://yhbt.net/unicorn/examples/init.sh
=== Master Process
diff --git a/Sandbox b/Sandbox
index d0f915e..651e5cd 100644
--- a/Sandbox
+++ b/Sandbox
@@ -34,7 +34,7 @@ is the primary issue with sandboxing tools such as Bundler and Isolate.
If you're bundling unicorn, use "bundle exec unicorn" (or "bundle exec
unicorn_rails") to start unicorn with the correct environment variables
-ref: https://bogomips.org/unicorn-public/9ECF07C4-5216-47BE-961D-AFC0F0C82060@internetfamo.us/
+ref: https://yhbt.net/unicorn-public/9ECF07C4-5216-47BE-961D-AFC0F0C82060@internetfamo.us/
Otherwise (if you choose to not sandbox your unicorn installation), we
expect the tips for Isolate (below) apply, too.
@@ -44,7 +44,7 @@ expect the tips for Isolate (below) apply, too.
This is no longer be an issue as of bundler 0.9.17
ref:
-https://bogomips.org/unicorn-public/8FC34B23-5994-41CC-B5AF-7198EF06909E@tramchase.com/
+https://yhbt.net/unicorn-public/8FC34B23-5994-41CC-B5AF-7198EF06909E@tramchase.com/
=== BUNDLE_GEMFILE for Capistrano users
diff --git a/archive/slrnpull.conf b/archive/slrnpull.conf
index fcfcafe..fd04f97 100644
--- a/archive/slrnpull.conf
+++ b/archive/slrnpull.conf
@@ -1,4 +1,4 @@
# group_name max expire headers_only
gmane.comp.lang.ruby.unicorn.general 1000000000 1000000000 0
-# usage: slrnpull -d $PWD -h news.gmane.org --no-post
+# usage: slrnpull -d $PWD -h news.gmane.io --no-post
diff --git a/examples/big_app_gc.rb b/examples/big_app_gc.rb
index 9d05719..c1bae10 100644
--- a/examples/big_app_gc.rb
+++ b/examples/big_app_gc.rb
@@ -1,2 +1,2 @@
-# see {Unicorn::OobGC}[https://bogomips.org/unicorn/Unicorn/OobGC.html]
+# see {Unicorn::OobGC}[https://yhbt.net/unicorn/Unicorn/OobGC.html]
# Unicorn::OobGC was broken in Unicorn v3.3.1 - v3.6.1 and fixed in v3.6.2
diff --git a/examples/logrotate.conf b/examples/logrotate.conf
index 77a01b5..c3aa40d 100644
--- a/examples/logrotate.conf
+++ b/examples/logrotate.conf
@@ -5,7 +5,7 @@
# https://linux.die.net/man/8/logrotate
#
# public logrotate-related discussion in our archives:
-# https://bogomips.org/unicorn-public/?q=logrotate
+# https://yhbt.net/unicorn-public/?q=logrotate
# Modify the following glob to match the logfiles your app writes to:
/var/log/unicorn_app/*.log {
@@ -33,7 +33,7 @@
systemctl kill -s SIGUSR1 unicorn@2.service
# Examples for other process management systems appreciated
- # Mail us at unicorn-public@bogomips.org
+ # Mail us at unicorn-public@yhbt.net
# (see above for archives)
# If you use a pid file and assuming your pid file
diff --git a/examples/nginx.conf b/examples/nginx.conf
index b6b69c1..c5026f9 100644
--- a/examples/nginx.conf
+++ b/examples/nginx.conf
@@ -113,7 +113,7 @@ http {
# try_files directive appeared in in nginx 0.7.27 and has stabilized
# over time. Older versions of nginx (e.g. 0.6.x) requires
# "if (!-f $request_filename)" which was less efficient:
- # https://bogomips.org/unicorn.git/tree/examples/nginx.conf?id=v3.3.1#n127
+ # https://yhbt.net/unicorn.git/tree/examples/nginx.conf?id=v3.3.1#n127
try_files $uri/index.html $uri.html $uri @app;
location @app {
diff --git a/examples/unicorn.conf.minimal.rb b/examples/unicorn.conf.minimal.rb
index 2d1bf0a..46fd634 100644
--- a/examples/unicorn.conf.minimal.rb
+++ b/examples/unicorn.conf.minimal.rb
@@ -1,9 +1,9 @@
# Minimal sample configuration file for Unicorn (not Rack) when used
# with daemonization (unicorn -D) started in your working directory.
#
-# See https://bogomips.org/unicorn/Unicorn/Configurator.html for complete
+# See https://yhbt.net/unicorn/Unicorn/Configurator.html for complete
# documentation.
-# See also https://bogomips.org/unicorn/examples/unicorn.conf.rb for
+# See also https://yhbt.net/unicorn/examples/unicorn.conf.rb for
# a more verbose configuration using more features.
listen 2007 # by default Unicorn listens on port 8080
diff --git a/examples/unicorn.conf.rb b/examples/unicorn.conf.rb
index d2897ef..d90bdc4 100644
--- a/examples/unicorn.conf.rb
+++ b/examples/unicorn.conf.rb
@@ -2,10 +2,10 @@
#
# This configuration file documents many features of Unicorn
# that may not be needed for some applications. See
-# https://bogomips.org/unicorn/examples/unicorn.conf.minimal.rb
+# https://yhbt.net/unicorn/examples/unicorn.conf.minimal.rb
# for a much simpler configuration file.
#
-# See https://bogomips.org/unicorn/Unicorn/Configurator.html for complete
+# See https://yhbt.net/unicorn/Unicorn/Configurator.html for complete
# documentation.
# Use at least one worker per core if you're on a dedicated server,
diff --git a/ext/unicorn_http/unicorn_http.rl b/ext/unicorn_http/unicorn_http.rl
index 8ef23bc..dfe3a63 100644
--- a/ext/unicorn_http/unicorn_http.rl
+++ b/ext/unicorn_http/unicorn_http.rl
@@ -487,7 +487,7 @@ static void set_url_scheme(VALUE env, VALUE *server_port)
* and X-Forwarded-Proto handling from this parser? We've had it
* forever and nobody has said anything against it, either.
* Anyways, please send comments to our public mailing list:
- * unicorn-public@bogomips.org (no HTML mail, no subscription necessary)
+ * unicorn-public@yhbt.net (no HTML mail, no subscription necessary)
*/
scheme = rb_hash_aref(env, g_http_x_forwarded_ssl);
if (!NIL_P(scheme) && STR_CSTR_EQ(scheme, "on")) {
diff --git a/lib/unicorn.rb b/lib/unicorn.rb
index dd5dff4..d5991fe 100644
--- a/lib/unicorn.rb
+++ b/lib/unicorn.rb
@@ -96,7 +96,7 @@ def self.builder(ru, op)
# returns an array of strings representing TCP listen socket addresses
# and Unix domain socket paths. This is useful for use with
- # Raindrops::Middleware under Linux: https://bogomips.org/raindrops/
+ # Raindrops::Middleware under Linux: https://yhbt.net/raindrops/
def self.listener_names
Unicorn::HttpServer::LISTENERS.map do |io|
Unicorn::SocketHelper.sock_name(io)
diff --git a/lib/unicorn/configurator.rb b/lib/unicorn/configurator.rb
index e8b76f5..c3a4f2d 100644
--- a/lib/unicorn/configurator.rb
+++ b/lib/unicorn/configurator.rb
@@ -3,11 +3,11 @@
# Implements a simple DSL for configuring a unicorn server.
#
-# See https://bogomips.org/unicorn/examples/unicorn.conf.rb and
-# https://bogomips.org/unicorn/examples/unicorn.conf.minimal.rb
+# See https://yhbt.net/unicorn/examples/unicorn.conf.rb and
+# https://yhbt.net/unicorn/examples/unicorn.conf.minimal.rb
# example configuration files. An example config file for use with
# nginx is also available at
-# https://bogomips.org/unicorn/examples/nginx.conf
+# https://yhbt.net/unicorn/examples/nginx.conf
#
# See the link:/TUNING.html document for more information on tuning unicorn.
class Unicorn::Configurator
diff --git a/lib/unicorn/http_server.rb b/lib/unicorn/http_server.rb
index 5334fa0..a52931a 100644
--- a/lib/unicorn/http_server.rb
+++ b/lib/unicorn/http_server.rb
@@ -6,7 +6,7 @@
# forked worker children.
#
# Users do not need to know the internals of this class, but reading the
-# {source}[https://bogomips.org/unicorn.git/tree/lib/unicorn/http_server.rb]
+# {source}[https://yhbt.net/unicorn.git/tree/lib/unicorn/http_server.rb]
# is education for programmers wishing to learn how unicorn works.
# See Unicorn::Configurator for information on how to configure unicorn.
class Unicorn::HttpServer
diff --git a/lib/unicorn/oob_gc.rb b/lib/unicorn/oob_gc.rb
index c4741a0..3b2f488 100644
--- a/lib/unicorn/oob_gc.rb
+++ b/lib/unicorn/oob_gc.rb
@@ -43,8 +43,8 @@
# use Unicorn::OobGC, 2, %r{\A/(?:expensive/foo|more_expensive/foo)}
#
# Feedback from users of early implementations of this module:
-# * https://bogomips.org/unicorn-public/0BFC98E9-072B-47EE-9A70-05478C20141B@lukemelia.com/
-# * https://bogomips.org/unicorn-public/AANLkTilUbgdyDv9W1bi-s_W6kq9sOhWfmuYkKLoKGOLj@mail.gmail.com/
+# * https://yhbt.net/unicorn-public/0BFC98E9-072B-47EE-9A70-05478C20141B@lukemelia.com/
+# * https://yhbt.net/unicorn-public/AANLkTilUbgdyDv9W1bi-s_W6kq9sOhWfmuYkKLoKGOLj@mail.gmail.com/
module Unicorn::OobGC
diff --git a/unicorn.gemspec b/unicorn.gemspec
index ceea831..a189f8d 100644
--- a/unicorn.gemspec
+++ b/unicorn.gemspec
@@ -15,14 +15,14 @@
s.authors = ['unicorn hackers']
s.summary = 'Rack HTTP server for fast clients and Unix'
s.description = File.read('README').split("\n\n")[1]
- s.email = %q{unicorn-public@bogomips.org}
+ s.email = %q{unicorn-public@yhbt.net}
s.executables = %w(unicorn unicorn_rails)
s.extensions = %w(ext/unicorn_http/extconf.rb)
s.extra_rdoc_files = IO.readlines('.document').map!(&:chomp!).keep_if do |f|
File.exist?(f)
end
s.files = manifest
- s.homepage = 'https://bogomips.org/unicorn/'
+ s.homepage = 'https://yhbt.net/unicorn/'
s.test_files = test_files
# technically we need ">= 1.9.3", too, but avoid the array here since
^ permalink raw reply related [relevance 10%]
* [PATCH] doc: s/bogomips.org/yhbt.net/g
@ 2020-01-14 7:46 10% Eric Wong
2020-01-14 7:46 10% ` Eric Wong
0 siblings, 1 reply; 27+ results
From: Eric Wong @ 2020-01-14 7:46 UTC (permalink / raw)
To: unicorn-public
bogomips.org is due to expire, soon, and I'm not willing to pay
extortionist fees to Ethos Capital/PIR/ICANN to keep a .org. So
it's at yhbt.net, for now, but it will change again to
whatever's affordable... Identity is overrated.
Tor users can use .onions and kick ICANN to the curb:
torsocks w3m http://unicorn.ou63pmih66umazou.onion/
torsocks git clone http://ou63pmih66umazou.onion/unicorn.git/
torsocks w3m http://ou63pmih66umazou.onion/unicorn-public/
While we're at it, `s/news.gmane.org/news.gmane.io/g', too.
(but I suspect that'll need to be resynched since our mail
"List-Id:" header is changing).
---
.olddoc.yml | 19 ++++++++++++-------
Documentation/unicorn.1 | 8 ++++----
Documentation/unicorn_rails.1 | 8 ++++----
FAQ | 2 +-
GNUmakefile | 4 ++--
HACKING | 2 +-
ISSUES | 24 ++++++++++++------------
KNOWN_ISSUES | 4 ++--
Links | 10 +++++-----
README | 12 ++++++------
SIGNALS | 2 +-
Sandbox | 4 ++--
archive/slrnpull.conf | 2 +-
examples/big_app_gc.rb | 2 +-
examples/logrotate.conf | 4 ++--
examples/nginx.conf | 2 +-
examples/unicorn.conf.minimal.rb | 4 ++--
examples/unicorn.conf.rb | 4 ++--
ext/unicorn_http/unicorn_http.rl | 2 +-
lib/unicorn.rb | 2 +-
lib/unicorn/configurator.rb | 6 +++---
lib/unicorn/http_server.rb | 2 +-
lib/unicorn/oob_gc.rb | 4 ++--
unicorn.gemspec | 4 ++--
24 files changed, 71 insertions(+), 66 deletions(-)
diff --git a/.olddoc.yml b/.olddoc.yml
index d2d340f..0609bdb 100644
--- a/.olddoc.yml
+++ b/.olddoc.yml
@@ -2,4 +2,5 @@
-cgit_url: https://bogomips.org/unicorn.git
-git_url: https://bogomips.org/unicorn.git
-rdoc_url: https://bogomips.org/unicorn/
-ml_url: https://bogomips.org/unicorn-public/
+cgit_url: https://yhbt.net/unicorn.git
+rdoc_url: https://yhbt.net/unicorn/
+ml_url:
+- https://yhbt.net/unicorn-public/
+- http://ou63pmih66umazou.onion/unicorn-public/
@@ -14 +15 @@ noindex:
-public_email: unicorn-public@bogomips.org
+public_email: unicorn-public@yhbt.net
@@ -16,2 +17,6 @@ nntp_url:
- - nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn
- - nntp://news.gmane.org/gmane.comp.lang.ruby.unicorn.general
+- nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn
+- nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.unicorn
+- nntp://news.gmane.io/gmane.comp.lang.ruby.unicorn.general
+source_code:
+- git clone https://yhbt.net/unicorn.git
+- torsocks git clone http://ou63pmih66umazou.onion/unicorn.git
diff --git a/Documentation/unicorn.1 b/Documentation/unicorn.1
index 3f8cb96..d76d40f 100644
--- a/Documentation/unicorn.1
+++ b/Documentation/unicorn.1
@@ -157 +157 @@ TTOU \- decrement the number of worker processes by one
-See the SIGNALS (https://bogomips.org/unicorn/SIGNALS.html) document for
+See the SIGNALS (https://yhbt.net/unicorn/SIGNALS.html) document for
@@ -207 +207 @@ the unicorn config file.
-.UR https://bogomips.org/unicorn/Unicorn/Configurator.html
+.UR https://yhbt.net/unicorn/Unicorn/Configurator.html
@@ -211 +211 @@ unicorn RDoc
-.UR https://bogomips.org/unicorn/
+.UR https://yhbt.net/unicorn/
@@ -222 +222 @@ Rackup HowTo
-The Unicorn Community <unicorn-public@bogomips.org>.
+The Unicorn Community <unicorn-public@yhbt.net>.
diff --git a/Documentation/unicorn_rails.1 b/Documentation/unicorn_rails.1
index 71c80be..fec0a2a 100644
--- a/Documentation/unicorn_rails.1
+++ b/Documentation/unicorn_rails.1
@@ -183 +183 @@ TTOU \- decrement the number of worker processes by one
-See the SIGNALS (https://bogomips.org/unicorn/SIGNALS.html) document for
+See the SIGNALS (https://yhbt.net/unicorn/SIGNALS.html) document for
@@ -192 +192 @@ unicorn(1)
-.UR https://bogomips.org/unicorn/Unicorn/Configurator.html
+.UR https://yhbt.net/unicorn/Unicorn/Configurator.html
@@ -196 +196 @@ unicorn RDoc
-.UR https://bogomips.org/unicorn/
+.UR https://yhbt.net/unicorn/
@@ -207 +207 @@ Rackup HowTo
-The Unicorn Community <unicorn-public@bogomips.org>.
+The Unicorn Community <unicorn-public@yhbt.net>.
diff --git a/FAQ b/FAQ
index 4ae2034..018ca92 100644
--- a/FAQ
+++ b/FAQ
@@ -10 +10 @@ overhead from bad requests.
-Ref: https://bogomips.org/unicorn-public/FC91211E-FD32-432C-92FC-0318714C2170@zendesk.com/
+Ref: https://yhbt.net/unicorn-public/FC91211E-FD32-432C-92FC-0318714C2170@zendesk.com/
diff --git a/GNUmakefile b/GNUmakefile
index 94c46ee..eac3473 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -196 +196 @@ doc: .document $(ext)/unicorn_http.c man html .olddoc.yml $(PLACEHOLDERS)
-# publishes docs to https://bogomips.org/unicorn/
+# publishes docs to https://yhbt.net/unicorn/
@@ -202 +202 @@ publish_doc:
- $(RSYNC) -av doc/ bogomips.org:/srv/bogomips/unicorn/
+ $(RSYNC) -av doc/ yhbt.net:/srv/yhbt/unicorn/
diff --git a/HACKING b/HACKING
index be1bb85..976bf92 100644
--- a/HACKING
+++ b/HACKING
@@ -60 +60 @@ When referencing mailing list posts, use
-<tt>https://bogomips.org/unicorn-public/$MESSAGE_ID/</tt> if possible
+<tt>https://yhbt.net/unicorn-public/$MESSAGE_ID/</tt> if possible
diff --git a/ISSUES b/ISSUES
index 473da2f..d11dc56 100644
--- a/ISSUES
+++ b/ISSUES
@@ -3 +3 @@
-mailto:unicorn-public@bogomips.org is the best place to report bugs,
+mailto:unicorn-public@yhbt.net is the best place to report bugs,
@@ -5,2 +5,2 @@ submit patches and/or obtain support after you have searched the
-{email archives}[https://bogomips.org/unicorn-public/] and
-{documentation}[https://bogomips.org/unicorn/].
+{email archives}[https://yhbt.net/unicorn-public/] and
+{documentation}[https://yhbt.net/unicorn/].
@@ -15,2 +15,2 @@ submit patches and/or obtain support after you have searched the
-* The email submission port (587) is enabled on the bogomips.org MX:
- https://bogomips.org/unicorn-public/20141004232241.GA23908@dcvr.yhbt.net/t/
+* The email submission port (587) is enabled on the yhbt.net MX:
+ https://yhbt.net/unicorn-public/20141004232241.GA23908@dcvr.yhbt.net/t/
@@ -20 +20 @@ can interoperate with any bug tracker which can Cc: us plain-text to
-mailto:unicorn-public@bogomips.org This includes the Debian BTS
+mailto:unicorn-public@yhbt.net This includes the Debian BTS
@@ -76,2 +76,2 @@ document distributed with git) on guidelines for patch submission.
-* public: mailto:unicorn-public@bogomips.org
-* nntp://news.gmane.org/gmane.comp.lang.ruby.unicorn.general
+* public: mailto:unicorn-public@yhbt.net
+* nntp://news.gmane.io/gmane.comp.lang.ruby.unicorn.general
@@ -79 +79 @@ document distributed with git) on guidelines for patch submission.
-* https://bogomips.org/unicorn-public/
+* https://yhbt.net/unicorn-public/
@@ -87 +87 @@ You can follow along via NNTP (read-only):
- nntp://news.gmane.org/gmane.comp.lang.ruby.unicorn.general
+ nntp://news.gmane.io/gmane.comp.lang.ruby.unicorn.general
@@ -91 +91 @@ Or Atom feeds:
- https://bogomips.org/unicorn-public/new.atom
+ https://yhbt.net/unicorn-public/new.atom
@@ -94 +94 @@ Or Atom feeds:
- The HTML archives at https://bogomips.org/unicorn-public/
+ The HTML archives at https://yhbt.net/unicorn-public/
diff --git a/KNOWN_ISSUES b/KNOWN_ISSUES
index ebd4822..0017f20 100644
--- a/KNOWN_ISSUES
+++ b/KNOWN_ISSUES
@@ -12 +12 @@ acceptable solution. Those issues are documented here.
- https://bogomips.org/unicorn-public/CAHBuKRj09FdxAgzsefJWotexw-7JYZGJMtgUp_dhjPz9VbKD6Q@mail.gmail.com/
+ https://yhbt.net/unicorn-public/CAHBuKRj09FdxAgzsefJWotexw-7JYZGJMtgUp_dhjPz9VbKD6Q@mail.gmail.com/
@@ -63 +63 @@ acceptable solution. Those issues are documented here.
- ref: https://bogomips.org/unicorn-public/20091014221552.GA30624@dcvr.yhbt.net/
+ ref: https://yhbt.net/unicorn-public/20091014221552.GA30624@dcvr.yhbt.net/
diff --git a/Links b/Links
index 10551a6..f81142d 100644
--- a/Links
+++ b/Links
@@ -5 +5 @@ listed below. If you have any links to add/change/remove, please tell us at
-mailto:unicorn-public@bogomips.org!
+mailto:unicorn-public@yhbt.net!
@@ -26 +26 @@ or services behind them.
-* {raindrops}[https://bogomips.org/raindrops/] - real-time stats for
+* {raindrops}[https://yhbt.net/raindrops/] - real-time stats for
@@ -29 +29 @@ or services behind them.
-* {UnXF}[https://bogomips.org/unxf/] Un-X-Forward* the Rack environment,
+* {UnXF}[https://yhbt.net/unxf/] Un-X-Forward* the Rack environment,
@@ -55 +55 @@ or services behind them.
- https://bogomips.org/mongrel-devel/
+ https://yhbt.net/mongrel-devel/
@@ -57 +57 @@ or services behind them.
-* {david}[https://bogomips.org/david.git] - a tool to explain why you need
+* {david}[https://yhbt.net/david.git] - a tool to explain why you need
diff --git a/README b/README
index 89467fc..0e95f48 100644
--- a/README
+++ b/README
@@ -83 +83 @@ You can get the latest source via git from the following locations
- https://bogomips.org/unicorn.git
+ https://yhbt.net/unicorn.git
@@ -88 +88 @@ You may browse the code from the web:
-* https://bogomips.org/unicorn.git
+* https://yhbt.net/unicorn.git
@@ -136 +136 @@ requests) go to the mailing list/newsgroup. See the ISSUES document for
-information on the {mailing list}[mailto:unicorn-public@bogomips.org].
+information on the {mailing list}[mailto:unicorn-public@yhbt.net].
@@ -138 +138 @@ information on the {mailing list}[mailto:unicorn-public@bogomips.org].
-The mailing list is archived at https://bogomips.org/unicorn-public/
+The mailing list is archived at https://yhbt.net/unicorn-public/
@@ -141 +141 @@ nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn and
-nntp://news.gmane.org/gmane.comp.lang.ruby.unicorn.general
+nntp://news.gmane.io/gmane.comp.lang.ruby.unicorn.general
@@ -144 +144 @@ For the latest on unicorn releases, you may also finger us at
-unicorn@bogomips.org or check our NEWS page (and subscribe to our Atom
+unicorn@yhbt.net or check our NEWS page (and subscribe to our Atom
diff --git a/SIGNALS b/SIGNALS
index 1af851d..7321f2b 100644
--- a/SIGNALS
+++ b/SIGNALS
@@ -11 +11 @@ One example init script is distributed with unicorn:
-https://bogomips.org/unicorn/examples/init.sh
+https://yhbt.net/unicorn/examples/init.sh
diff --git a/Sandbox b/Sandbox
index d0f915e..651e5cd 100644
--- a/Sandbox
+++ b/Sandbox
@@ -37 +37 @@ unicorn_rails") to start unicorn with the correct environment variables
-ref: https://bogomips.org/unicorn-public/9ECF07C4-5216-47BE-961D-AFC0F0C82060@internetfamo.us/
+ref: https://yhbt.net/unicorn-public/9ECF07C4-5216-47BE-961D-AFC0F0C82060@internetfamo.us/
@@ -47 +47 @@ ref:
-https://bogomips.org/unicorn-public/8FC34B23-5994-41CC-B5AF-7198EF06909E@tramchase.com/
+https://yhbt.net/unicorn-public/8FC34B23-5994-41CC-B5AF-7198EF06909E@tramchase.com/
diff --git a/archive/slrnpull.conf b/archive/slrnpull.conf
index fcfcafe..fd04f97 100644
--- a/archive/slrnpull.conf
+++ b/archive/slrnpull.conf
@@ -4 +4 @@ gmane.comp.lang.ruby.unicorn.general 1000000000 1000000000 0
-# usage: slrnpull -d $PWD -h news.gmane.org --no-post
+# usage: slrnpull -d $PWD -h news.gmane.io --no-post
diff --git a/examples/big_app_gc.rb b/examples/big_app_gc.rb
index 9d05719..c1bae10 100644
--- a/examples/big_app_gc.rb
+++ b/examples/big_app_gc.rb
@@ -1 +1 @@
-# see {Unicorn::OobGC}[https://bogomips.org/unicorn/Unicorn/OobGC.html]
+# see {Unicorn::OobGC}[https://yhbt.net/unicorn/Unicorn/OobGC.html]
diff --git a/examples/logrotate.conf b/examples/logrotate.conf
index 77a01b5..c3aa40d 100644
--- a/examples/logrotate.conf
+++ b/examples/logrotate.conf
@@ -8 +8 @@
-# https://bogomips.org/unicorn-public/?q=logrotate
+# https://yhbt.net/unicorn-public/?q=logrotate
@@ -36 +36 @@
- # Mail us at unicorn-public@bogomips.org
+ # Mail us at unicorn-public@yhbt.net
diff --git a/examples/nginx.conf b/examples/nginx.conf
index b6b69c1..c5026f9 100644
--- a/examples/nginx.conf
+++ b/examples/nginx.conf
@@ -116 +116 @@ http {
- # https://bogomips.org/unicorn.git/tree/examples/nginx.conf?id=v3.3.1#n127
+ # https://yhbt.net/unicorn.git/tree/examples/nginx.conf?id=v3.3.1#n127
diff --git a/examples/unicorn.conf.minimal.rb b/examples/unicorn.conf.minimal.rb
index 2d1bf0a..46fd634 100644
--- a/examples/unicorn.conf.minimal.rb
+++ b/examples/unicorn.conf.minimal.rb
@@ -4 +4 @@
-# See https://bogomips.org/unicorn/Unicorn/Configurator.html for complete
+# See https://yhbt.net/unicorn/Unicorn/Configurator.html for complete
@@ -6 +6 @@
-# See also https://bogomips.org/unicorn/examples/unicorn.conf.rb for
+# See also https://yhbt.net/unicorn/examples/unicorn.conf.rb for
diff --git a/examples/unicorn.conf.rb b/examples/unicorn.conf.rb
index d2897ef..d90bdc4 100644
--- a/examples/unicorn.conf.rb
+++ b/examples/unicorn.conf.rb
@@ -5 +5 @@
-# https://bogomips.org/unicorn/examples/unicorn.conf.minimal.rb
+# https://yhbt.net/unicorn/examples/unicorn.conf.minimal.rb
@@ -8 +8 @@
-# See https://bogomips.org/unicorn/Unicorn/Configurator.html for complete
+# See https://yhbt.net/unicorn/Unicorn/Configurator.html for complete
diff --git a/ext/unicorn_http/unicorn_http.rl b/ext/unicorn_http/unicorn_http.rl
index 8ef23bc..dfe3a63 100644
--- a/ext/unicorn_http/unicorn_http.rl
+++ b/ext/unicorn_http/unicorn_http.rl
@@ -490 +490 @@ static void set_url_scheme(VALUE env, VALUE *server_port)
- * unicorn-public@bogomips.org (no HTML mail, no subscription necessary)
+ * unicorn-public@yhbt.net (no HTML mail, no subscription necessary)
diff --git a/lib/unicorn.rb b/lib/unicorn.rb
index dd5dff4..d5991fe 100644
--- a/lib/unicorn.rb
+++ b/lib/unicorn.rb
@@ -99 +99 @@ def self.builder(ru, op)
- # Raindrops::Middleware under Linux: https://bogomips.org/raindrops/
+ # Raindrops::Middleware under Linux: https://yhbt.net/raindrops/
diff --git a/lib/unicorn/configurator.rb b/lib/unicorn/configurator.rb
index e8b76f5..c3a4f2d 100644
--- a/lib/unicorn/configurator.rb
+++ b/lib/unicorn/configurator.rb
@@ -6,2 +6,2 @@
-# See https://bogomips.org/unicorn/examples/unicorn.conf.rb and
-# https://bogomips.org/unicorn/examples/unicorn.conf.minimal.rb
+# See https://yhbt.net/unicorn/examples/unicorn.conf.rb and
+# https://yhbt.net/unicorn/examples/unicorn.conf.minimal.rb
@@ -10 +10 @@
-# https://bogomips.org/unicorn/examples/nginx.conf
+# https://yhbt.net/unicorn/examples/nginx.conf
diff --git a/lib/unicorn/http_server.rb b/lib/unicorn/http_server.rb
index 5334fa0..a52931a 100644
--- a/lib/unicorn/http_server.rb
+++ b/lib/unicorn/http_server.rb
@@ -9 +9 @@
-# {source}[https://bogomips.org/unicorn.git/tree/lib/unicorn/http_server.rb]
+# {source}[https://yhbt.net/unicorn.git/tree/lib/unicorn/http_server.rb]
diff --git a/lib/unicorn/oob_gc.rb b/lib/unicorn/oob_gc.rb
index c4741a0..3b2f488 100644
--- a/lib/unicorn/oob_gc.rb
+++ b/lib/unicorn/oob_gc.rb
@@ -46,2 +46,2 @@
-# * https://bogomips.org/unicorn-public/0BFC98E9-072B-47EE-9A70-05478C20141B@lukemelia.com/
-# * https://bogomips.org/unicorn-public/AANLkTilUbgdyDv9W1bi-s_W6kq9sOhWfmuYkKLoKGOLj@mail.gmail.com/
+# * https://yhbt.net/unicorn-public/0BFC98E9-072B-47EE-9A70-05478C20141B@lukemelia.com/
+# * https://yhbt.net/unicorn-public/AANLkTilUbgdyDv9W1bi-s_W6kq9sOhWfmuYkKLoKGOLj@mail.gmail.com/
diff --git a/unicorn.gemspec b/unicorn.gemspec
index ceea831..a189f8d 100644
--- a/unicorn.gemspec
+++ b/unicorn.gemspec
@@ -18 +18 @@
- s.email = %q{unicorn-public@bogomips.org}
+ s.email = %q{unicorn-public@yhbt.net}
@@ -25 +25 @@
- s.homepage = 'https://bogomips.org/unicorn/'
+ s.homepage = 'https://yhbt.net/unicorn/'
^ permalink raw reply related [relevance 10%]
* [PATCH] doc: update more URLs to use HTTPS and avoid redirects
@ 2018-11-07 23:38 18% Eric Wong
0 siblings, 0 replies; 27+ results
From: Eric Wong @ 2018-11-07 23:38 UTC (permalink / raw)
To: unicorn-public
Latency from redirects is painful, and HTTPS can protect privacy
in some cases.
---
.olddoc.yml | 2 +-
Application_Timeouts | 8 ++++----
Documentation/unicorn.1.txt | 2 +-
Documentation/unicorn_rails.1.txt | 2 +-
LICENSE | 4 ++--
Links | 12 ++++++------
README | 8 ++++----
Sandbox | 4 ++--
examples/logrotate.conf | 2 +-
examples/nginx.conf | 5 +++--
lib/unicorn/configurator.rb | 2 +-
lib/unicorn/http_request.rb | 2 +-
lib/unicorn/http_server.rb | 2 +-
lib/unicorn/util.rb | 2 +-
t/README | 8 ++++----
15 files changed, 33 insertions(+), 32 deletions(-)
diff --git a/.olddoc.yml b/.olddoc.yml
index cacc0ab..d2d340f 100644
--- a/.olddoc.yml
+++ b/.olddoc.yml
@@ -1,6 +1,6 @@
---
cgit_url: https://bogomips.org/unicorn.git
-git_url: git://bogomips.org/unicorn.git
+git_url: https://bogomips.org/unicorn.git
rdoc_url: https://bogomips.org/unicorn/
ml_url: https://bogomips.org/unicorn-public/
merge_html:
diff --git a/Application_Timeouts b/Application_Timeouts
index 561a1cc..4dcd954 100644
--- a/Application_Timeouts
+++ b/Application_Timeouts
@@ -23,10 +23,10 @@ Most database adapters allow configurable timeouts.
Net::HTTP and Net::SMTP in the Ruby standard library allow
configurable timeouts.
-Even for things as fast as {memcached}[http://memcached.org/],
-{dalli}[http://rubygems.org/gems/dalli],
-{memcached}[http://rubygems.org/gems/memcached] and
-{memcache-client}[http://rubygems.org/gems/memcache-client] RubyGems all
+Even for things as fast as {memcached}[https://memcached.org/],
+{dalli}[https://rubygems.org/gems/dalli],
+{memcached}[https://rubygems.org/gems/memcached] and
+{memcache-client}[https://rubygems.org/gems/memcache-client] RubyGems all
offer configurable timeouts.
Consult the relevant documentation for the libraries you use on
diff --git a/Documentation/unicorn.1.txt b/Documentation/unicorn.1.txt
index e692078..da7281d 100644
--- a/Documentation/unicorn.1.txt
+++ b/Documentation/unicorn.1.txt
@@ -182,6 +182,6 @@ the unicorn config file.
* [Rackup HowTo][3]
[1]: https://bogomips.org/unicorn/
-[2]: http://www.rubydoc.info/github/rack/rack/
+[2]: https://www.rubydoc.info/github/rack/rack/
[3]: https://github.com/rack/rack/wiki/tutorial-rackup-howto
[4]: https://bogomips.org/unicorn/SIGNALS.html
diff --git a/Documentation/unicorn_rails.1.txt b/Documentation/unicorn_rails.1.txt
index 088e2ff..fb0e60f 100644
--- a/Documentation/unicorn_rails.1.txt
+++ b/Documentation/unicorn_rails.1.txt
@@ -170,6 +170,6 @@ used by Unicorn.
* [Rackup HowTo][3]
[1]: https://bogomips.org/unicorn/
-[2]: http://www.rubydoc.info/github/rack/rack/
+[2]: https://www.rubydoc.info/github/rack/rack/
[3]: https://github.com/rack/rack/wiki/tutorial-rackup-howto
[4]: https://bogomips.org/unicorn/SIGNALS.html
diff --git a/LICENSE b/LICENSE
index 5b6458e..e986865 100644
--- a/LICENSE
+++ b/LICENSE
@@ -8,8 +8,8 @@ any later version. We currently prefer the GPLv3 or later for
derivative works, but the GPLv2 is fine.
The complete texts of the GPLv2 and GPLv3 are below:
-GPLv2 - http://www.gnu.org/licenses/gpl-2.0.txt
-GPLv3 - http://www.gnu.org/licenses/gpl-3.0.txt
+GPLv2 - https://www.gnu.org/licenses/gpl-2.0.txt
+GPLv3 - https://www.gnu.org/licenses/gpl-3.0.txt
You may (against our _preference_) also use the Ruby 1.8 license terms
which we inherited from the original Mongrel project when we forked it:
diff --git a/Links b/Links
index 475a6c0..baba9c7 100644
--- a/Links
+++ b/Links
@@ -10,7 +10,7 @@ The unicorn project is not responsible for the content in these links.
Furthermore, the unicorn project has never, does not and will never endorse:
* any for-profit entities or services
-* any non-{Free Software}[http://www.gnu.org/philosophy/free-sw.html]
+* any non-{Free Software}[https://www.gnu.org/philosophy/free-sw.html]
The existence of these links does not imply endorsement of any entities
or services behind them.
@@ -31,25 +31,25 @@ or services behind them.
=== unicorn is written to work with
-* {Rack}[http://rack.github.io/] - a minimal interface between webservers
+* {Rack}[https://rack.github.io/] - a minimal interface between webservers
supporting Ruby and Ruby frameworks
* {Ruby}[https://www.ruby-lang.org/en/] - the programming language of
Rack and unicorn
-* {nginx}[http://nginx.org/] (Free versions) -
+* {nginx}[https://nginx.org/] (Free versions) -
the reverse proxy for use with unicorn
=== Derivatives
-* {Green Unicorn}[http://gunicorn.org/] - a Python version of unicorn
+* {Green Unicorn}[https://gunicorn.org/] - a Python version of unicorn
-* {Starman}[http://search.cpan.org/dist/Starman/] - Plack/PSGI version
+* {Starman}[https://metacpan.org/release/Starman/] - Plack/PSGI version
of unicorn
=== Prior Work
-* {Mongrel}[http://rubygems.org/gems/mongrel] - the awesome webserver
+* {Mongrel}[https://rubygems.org/gems/mongrel] - the awesome webserver
unicorn is based on
* {david}[https://bogomips.org/david.git] - a tool to explain why you need
diff --git a/README b/README
index 29e04b4..5e5ccf7 100644
--- a/README
+++ b/README
@@ -10,7 +10,7 @@ both the the request and response in between unicorn and slow clients.
* Designed for Rack, Unix, fast clients, and ease-of-debugging. We
cut out everything that is better supported by the operating system,
- {nginx}[http://nginx.org/] or {Rack}[http://rack.github.io/].
+ {nginx}[https://nginx.org/] or {Rack}[https://rack.github.io/].
* Compatible with Ruby 1.9.3 and later.
unicorn 4.x remains supported for Ruby 1.8 users.
@@ -77,13 +77,13 @@ You may install it via RubyGems on RubyGems.org:
You can get the latest source via git from the following locations
(these versions may not be stable):
- git://bogomips.org/unicorn.git
- git://repo.or.cz/unicorn.git (mirror)
+ https://bogomips.org/unicorn.git
+ https://repo.or.cz/unicorn.git (mirror)
You may browse the code from the web:
* https://bogomips.org/unicorn.git
-* http://repo.or.cz/w/unicorn.git (gitweb)
+* https://repo.or.cz/w/unicorn.git (gitweb)
See the HACKING guide on how to contribute and build prerelease gems
from git.
diff --git a/Sandbox b/Sandbox
index e10b36d..d0f915e 100644
--- a/Sandbox
+++ b/Sandbox
@@ -3,7 +3,7 @@
Since unicorn includes executables and is usually used to start a Ruby
process, there are certain caveats to using it with tools that sandbox
RubyGems installations such as
-{Bundler}[http://bundler.io/] or
+{Bundler}[https://bundler.io/] or
{Isolate}[https://github.com/jbarnette/isolate].
== General deployment
@@ -66,7 +66,7 @@ before_exec hook as illustrated by https://gist.github.com/534668
Ruby 2.0.0 enforces FD_CLOEXEC on file descriptors by default. unicorn
has been prepared for this behavior since unicorn 4.1.0, and bundler
needs the "--keep-file-descriptors" option for "bundle exec":
-http://bundler.io/man/bundle-exec.1.html
+https://bundler.io/man/bundle-exec.1.html
== Isolate
diff --git a/examples/logrotate.conf b/examples/logrotate.conf
index 437f6c6..77a01b5 100644
--- a/examples/logrotate.conf
+++ b/examples/logrotate.conf
@@ -2,7 +2,7 @@
# /etc/logrotate.d/unicorn_app on my Debian systems
#
# See the logrotate(8) manpage for more information:
-# http://linux.die.net/man/8/logrotate
+# https://linux.die.net/man/8/logrotate
#
# public logrotate-related discussion in our archives:
# https://bogomips.org/unicorn-public/?q=logrotate
diff --git a/examples/nginx.conf b/examples/nginx.conf
index e25712f..b6b69c1 100644
--- a/examples/nginx.conf
+++ b/examples/nginx.conf
@@ -56,7 +56,8 @@ http {
# to configure it all in one place here for static files and also
# to disable gzip for clients who don't get gzip/deflate right.
# There are other gzip settings that may be needed used to deal with
- # bad clients out there, see http://wiki.nginx.org/NginxHttpGzipModule
+ # bad clients out there, see
+ # https://nginx.org/en/docs/http/ngx_http_gzip_module.html
gzip on;
gzip_http_version 1.0;
gzip_proxied any;
@@ -117,7 +118,7 @@ http {
location @app {
# an HTTP header important enough to have its own Wikipedia entry:
- # http://en.wikipedia.org/wiki/X-Forwarded-For
+ # https://en.wikipedia.org/wiki/X-Forwarded-For
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# enable this if you forward HTTPS traffic to unicorn,
diff --git a/lib/unicorn/configurator.rb b/lib/unicorn/configurator.rb
index d426edf..e8b76f5 100644
--- a/lib/unicorn/configurator.rb
+++ b/lib/unicorn/configurator.rb
@@ -238,7 +238,7 @@ def before_exec(*args, &block)
# server 192.168.0.9:8080 fail_timeout=0;
# }
#
- # See http://nginx.org/en/docs/http/ngx_http_upstream_module.html
+ # See https://nginx.org/en/docs/http/ngx_http_upstream_module.html
# for more details on nginx upstream configuration.
def timeout(seconds)
set_int(:timeout, seconds, 3)
diff --git a/lib/unicorn/http_request.rb b/lib/unicorn/http_request.rb
index 8bb884b..bcc1f2d 100644
--- a/lib/unicorn/http_request.rb
+++ b/lib/unicorn/http_request.rb
@@ -65,7 +65,7 @@ def read(socket)
clear
e = env
- # From http://www.ietf.org/rfc/rfc3875:
+ # From https://www.ietf.org/rfc/rfc3875:
# "Script authors should be aware that the REMOTE_ADDR and
# REMOTE_HOST meta-variables (see sections 4.1.8 and 4.1.9)
# may not identify the ultimate source of the request. They
diff --git a/lib/unicorn/http_server.rb b/lib/unicorn/http_server.rb
index 62f6171..5334fa0 100644
--- a/lib/unicorn/http_server.rb
+++ b/lib/unicorn/http_server.rb
@@ -84,7 +84,7 @@ def initialize(app, options = {})
# * The master process never closes or reinitializes this once
# initialized. Signal handlers in the master process will write to
# it to wake up the master from IO.select in exactly the same manner
- # djb describes in http://cr.yp.to/docs/selfpipe.html
+ # djb describes in https://cr.yp.to/docs/selfpipe.html
#
# * The workers immediately close the pipe they inherit. See the
# Unicorn::Worker class for the pipe workers use.
diff --git a/lib/unicorn/util.rb b/lib/unicorn/util.rb
index 501930c..b826de4 100644
--- a/lib/unicorn/util.rb
+++ b/lib/unicorn/util.rb
@@ -64,7 +64,7 @@ def self.reopen_logs
fp.reopen(fp.path, "a")
else
# We should not need this workaround, Ruby can be fixed:
- # http://bugs.ruby-lang.org/issues/9036
+ # https://bugs.ruby-lang.org/issues/9036
# MRI will not call call fclose(3) or freopen(3) here
# since there's no associated std{in,out,err} FILE * pointer
# This should atomically use dup3(2) (or dup2(2)) syscall
diff --git a/t/README b/t/README
index bcaf3ce..0d9b697 100644
--- a/t/README
+++ b/t/README
@@ -10,17 +10,17 @@ comfortable writing integration tests with.
== Requirements
-* {Ruby 1.9.3+}[https://www.ruby-lang.org/] (duh!)
-* {GNU make}[http://www.gnu.org/software/make/]
+* {Ruby 1.9.3+}[https://www.ruby-lang.org/en/] (duh!)
+* {GNU make}[https://www.gnu.org/software/make/]
* {socat}[http://www.dest-unreach.org/socat/]
-* {curl}[http://curl.haxx.se/]
+* {curl}[https://curl.haxx.se/]
* standard UNIX shell utilities (Bourne sh, awk, sed, grep, ...)
We do not use bashisms or any non-portable, non-POSIX constructs
in our shell code. We use the "pipefail" option if available and
mainly test with {ksh}[http://kornshell.com/], but occasionally
with {dash}[http://gondor.apana.org.au/~herbert/dash/] and
-{bash}[http://www.gnu.org/software/bash/], too.
+{bash}[https://www.gnu.org/software/bash/], too.
== Running Tests
--
EW
^ permalink raw reply related [relevance 18%]
* Re: Bug, probably related to Unicoen
@ 2017-09-14 9:15 4% ` Eric Wong
0 siblings, 0 replies; 27+ results
From: Eric Wong @ 2017-09-14 9:15 UTC (permalink / raw)
To: Felix Yasnopolski; +Cc: unicorn-public
Felix Yasnopolski <felix.yasnopolski@gmail.com> wrote:
> We use Ruby v2.2.3, Rails v4.2.4, Unicorn v5.1.0 in production.
>
> ActiveRecord validation rules and callbacks for all models of app has
> been disabled after unicorn restart (from log rotation script). Here
> it is
Wow, that's a new one... I haven't used Rails in years, but it's
certainly not intentional behavior on the part of unicorn.
Hopefully somebody else with Rails knowledge can chime in.
Some questions:
Do you have anything which overrides USR1?
Are the logs getting rotated correctly?
(more below ...)
> /var/www/fitness_crm/shared/log/production.log
> /var/www/fitness_crm/shared/log/unicorn.stderr.log
> /var/www/fitness_crm/shared/log/unicorn.stdout.log {
> daily
> missingok
> rotate 30
> compress
> notifempty
> create 640 deploy deploy
> sharedscripts
> postrotate
> kill -s USR2 `cat
> /var/www/fitness_crm/shared/tmp/pids/unicorn.pid`
> endscript
> }
>
> We've changed the script to send USR1 instead of USR2, but nothing has
> changed. When USR1 is sent validations/callbacks simply keep being
> disabled. Here is our unicorn configuration file
>
> working_directory "/var/www/fitness_crm/current"
> pid "/var/www/fitness_crm/shared/tmp/pids/unicorn.pid"
> stdout_path "/var/www/fitness_crm/shared/log/unicorn.stdout.log"
> stderr_path "/var/www/fitness_crm/shared/log/unicorn.stderr.log"
OK, that looks right.
Do your logs show the log rotations as they're happening, at least?
Anything else pop up in the logs which might help us figure out
what's wrong? (for example, do you have dying workers)
> listen "/tmp/unicorn.fitness_crm_production.sock"
>
> worker_processes 8
> timeout 30
>
> preload_app true
Can you try omitting preload_app and see if you can reproduce
the problem? The big reason preload_app is `false' by default
is it could break some code...
And probably use only 1 worker to avoid memory
overhead/excessive log spew during debugging.
> before_exec do |server|
> ENV["BUNDLE_GEMFILE"] = "/var/www/fitness_crm/current/Gemfile"
> end
>
> before_fork do |server, worker|
> # Disconnect since the database connection will not carry over
> if defined? ActiveRecord::Base
> ActiveRecord::Base.connection.disconnect!
> end
>
> # Quit the old unicorn process
> old_pid = "#{server.config[: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
>
> if defined?(Resque)
> Resque.redis.quit
> end
>
> sleep 1
> end
>
> after_fork do |server, worker|
> # Start up the database connection again in the worker
> if defined?(ActiveRecord::Base)
> ActiveRecord::Base.establish_connection
> end
>
> if defined?(Resque)
> Resque.redis = 'localhost:6379'
> end
> end
If log rotations (via USR1) fails (e.g. due to permission
error), the workers die and get replaced, instead. This allows
the log files to be released and rotated in "brute force"
fashion...
Can you reproduce the problem by sending a QUIT, TERM, or KILL
signal directly to a worker process? (Also, note the time
interval between initial master startup and your test)
A later-spawned worker could behave differently/strangely
from an originally-spawned one...
Finally, can you reproduce your original problem by sending USR1
to the master immediately after a fresh start?
With logrotate (which only runs intermittently), the problem
could be manifesting from an app timeout or time skew of some
sort interacting poorly with preload_app and respawned workers.
> After this we kill unicorn and start it manually with command:
>
> bundle exec unicorn -D -c
> /var/www/fitness_crm/shared/config/unicorn.rb -E production
>
> After this everything is good and validations and callbacks are
> enabled again. Please, help to find out what is the reason of such a
> behavior and how to fix it.
This is why I gave the time skew/timeout hypothesis above.
Otherwise; I'm out of ideas, for now (and falling asleep).
Hoping somebody more awake with modern Rails knowledge can chime
in and help with things I'm missing.
Again; one of the first unicorn-specific steps for
troubleshooting is to disable preload_app and use a single
worker process which you can trace more easily.
^ permalink raw reply [relevance 4%]
* [ANN] unicorn 5.2.0 - Rack HTTP server for fast clients and *nix
[not found] <20161031-unicorn-5.2.0-released@bogomips.org>
@ 2016-10-31 20:04 4% ` Eric Wong
0 siblings, 0 replies; 27+ results
From: Eric Wong @ 2016-10-31 20:04 UTC (permalink / raw)
To: ruby-talk, unicorn-public; +Cc: Mishael A Sibiryakov
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.
* https://bogomips.org/unicorn/
* public list: unicorn-public@bogomips.org
* mail archives: https://bogomips.org/unicorn-public/
* git clone git://bogomips.org/unicorn.git
* https://bogomips.org/unicorn/NEWS.atom.xml
* nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn
Changes:
Most notably, this release allows us to support requests with
lines delimited by LF-only, as opposed to the standard CRLF
pair and allowed by RFC 2616 sec 19.3.
Thanks to Mishael A Sibiryakov for the explanation and change:
https://bogomips.org/unicorn-public/1476954332.1736.156.camel@junki.org/
Thanks to Let's Encrypt, the website also moves to HTTPS
<https://bogomips.org/unicorn/> to improve reader privacy. The
"unicorn.bogomips.org" subdomain will be retired soon to reduce
subjectAltName bloat and speed up certificate renewals.
There's also the usual round of documentation and example
updates, too.
Eric Wong (7):
examples/init.sh: update to reduce upgrade raciness
doc: systemd should only kill master in example
examples/logrotate.conf: update example for systemd
doc: update gmane URLs to point to our own archives
relocate website to https://bogomips.org/unicorn/
TODO: remove Rack 2.x item
build: "install-gem" target avoids network
Mishael A Sibiryakov (1):
Add some tolerance (RFC2616 sec. 19.3)
^ permalink raw reply [relevance 4%]
* [PATCH] examples/logrotate.conf: update example for systemd
@ 2016-06-20 20:00 35% Eric Wong
0 siblings, 0 replies; 27+ results
From: Eric Wong @ 2016-06-20 20:00 UTC (permalink / raw)
To: unicorn-public
...And add placeholders for other systems
---
Leaving out the part for using a backup service :>
for i in /var/log/unicorn_app/*.log.gz
do
curl -sSf -T $i cloud.nsa.gov/store && rm $i
done
examples/logrotate.conf | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/examples/logrotate.conf b/examples/logrotate.conf
index 03fefc6..437f6c6 100644
--- a/examples/logrotate.conf
+++ b/examples/logrotate.conf
@@ -3,6 +3,9 @@
#
# See the logrotate(8) manpage for more information:
# http://linux.die.net/man/8/logrotate
+#
+# public logrotate-related discussion in our archives:
+# https://bogomips.org/unicorn-public/?q=logrotate
# Modify the following glob to match the logfiles your app writes to:
/var/log/unicorn_app/*.log {
@@ -22,7 +25,19 @@
# config. Unicorn supports the USR1 signal and we send it
# as our "lastaction" action:
lastaction
- # assuming your pid file is in /var/run/unicorn_app/pid
+ # For systemd users, assuming you use two services
+ # (as recommended) to allow zero-downtime upgrades.
+ # Only one service needs to be started, but signaling
+ # both here is harmless as long as they're both enabled
+ systemctl kill -s SIGUSR1 unicorn@1.service
+ systemctl kill -s SIGUSR1 unicorn@2.service
+
+ # Examples for other process management systems appreciated
+ # Mail us at unicorn-public@bogomips.org
+ # (see above for archives)
+
+ # If you use a pid file and assuming your pid file
+ # is in /var/run/unicorn_app/pid
pid=/var/run/unicorn_app/pid
test -s $pid && kill -USR1 "$(cat $pid)"
endscript
^ permalink raw reply related [relevance 35%]
* [PATCH] doc: further trimming to reduce noise
@ 2016-03-31 1:41 5% Eric Wong
0 siblings, 0 replies; 27+ results
From: Eric Wong @ 2016-03-31 1:41 UTC (permalink / raw)
To: unicorn-public
It's not worth mentioning pre-Rack versions of Rails anymore,
and there are a few async Rack applications reliant on
EventMachine which we do not use.
Some uses of chunked request decoding are not well-handled
with nginx in front, anyways; so avoid mentioning them.
Additionally, avoid introducing new terms into the lexicon
and just refer to "mailing list" as a generic term.
---
ISSUES | 8 +++-----
README | 7 +------
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/ISSUES b/ISSUES
index 394c852..21bd013 100644
--- a/ISSUES
+++ b/ISSUES
@@ -5,7 +5,7 @@ submit patches and/or obtain support after you have searched the
{email archives}[http://bogomips.org/unicorn-public/] and
{documentation}[http://unicorn.bogomips.org/].
-* No subscription will ever be required to email the public inbox.
+* No subscription will ever be required to email us
* Cc: all participants in a thread or commit, as subscription is optional
* Do not {top post}[http://catb.org/jargon/html/T/top-post.html] in replies
* Quote as little as possible of the message you're replying to
@@ -69,9 +69,7 @@ document distributed with git) on guidelines for patch submission.
* nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn
* http://bogomips.org/unicorn-public/
-We operate a {public-inbox}[http://public-inbox.org/] which
-feeds the mailing list. Subscription is optional, so Cc:
-all participants.
+Mailing list subscription is optional, so Cc: all participants.
You can follow along via NNTP:
@@ -86,7 +84,7 @@ Or Atom feeds:
also has links to per-thread Atom feeds and downloadable
mboxes.
-You may also subscribe via plain-text email:
+You may optionally subscribe via plain-text email:
mailto:unicorn-public+subscribe@bogomips.org
(and confirming the auto-reply)
diff --git a/README b/README
index 11de938..8079f37 100644
--- a/README
+++ b/README
@@ -27,9 +27,6 @@ both the the request and response in between unicorn and slow clients.
all run within their own isolated address space and only serve one
client at a time for maximum robustness.
-* Supports all Rack applications, along with pre-Rack versions of
- Ruby on Rails via a Rack wrapper.
-
* Builtin reopening of all log files in your application via
USR1 signal. This allows logrotate to rotate files atomically and
quickly via rename instead of the racy and slow copytruncate method.
@@ -54,9 +51,7 @@ both the the request and response in between unicorn and slow clients.
* Simple and easy Ruby DSL for configuration.
-* Decodes chunked transfers on-the-fly, thus allowing upload progress
- notification to be implemented as well as being able to tunnel
- arbitrary stream-based protocols over HTTP.
+* Decodes chunked requests on-the-fly.
== License
--
EW
^ permalink raw reply related [relevance 5%]
* Re: unicorn log attack?
[not found] <56AAAD0A.8000807@icloud.com>
@ 2016-01-30 9:34 5% ` Eric Wong
0 siblings, 0 replies; 27+ results
From: Eric Wong @ 2016-01-30 9:34 UTC (permalink / raw)
To: Lawrence Pit; +Cc: unicorn-public
Lawrence Pit <lawrencepit@icloud.com> wrote:
> Hi Eric,
>
> I'm writing to you directly instead of to the unicorn-public list.
Which got your HTML email tarpitted in my spam folder instead of
being bounced back right away so you could fix it :)
> I noticed yesterday our unicorn.log files, which are usually tiny,
> were gigantic in size. Fortunately, this was caused by a friendly
> attack, but had they persisted I think we would've run out of
> diskspace (of which we would've been warned in advance, so we
> could've dealt with the situation I suppose had it happened)
>
> Upon inspection it seems requests were received as shown below (
> I've cut out the middle part of the value that was part of the form
> body that was posted )
>
> The log statement is printed out by unicorn.rb method +log_error+.
>
> I'm not sure this is a unicorn issue, and thinking more an issue of
> how we developers should deal with repeatedly receiving the same
> sort of (sometimes very large) exceptions? Any advice?
Right, not a unicorn issue :)
Use logrotate or similar, compress your logs frequently, be
mindful of what you dump from your app; and watch your disk
usage (which you seem to be doing already), but that includes
emails :)
In ancient times (perhaps it was the Mongrel days), the server
itself would dump the contents of bad HTTP requests for
debugging; but given the amount of probes/scans I saw: it wasn't
worth it. We don't even log things like aborted/dropped
connections.
Since the backtrace below clearly shows the error happened from
something your application was doing; I don't consider it the
responsibility of the app server to sanitize it.
> ps. if you want to reply via the list that's fine by me.
Done :) but I've shortened the backtrace for readability
> E, [2016-01-26T11:23:49.499928 srv23 28932] unicorn: app error:
> invalid %-encoding (stri%26%23%30%30%32%
<snip>
> [ CUT VERY LARGE VALUE ]
<snip :>
> (ArgumentError)
> /usr/local/lib/ruby/2.2.0/uri/common.rb:382:in
> `decode_www_form_component'
> /rack-1.5.5/lib/rack/utils.rb:42:in
> `unescape'
> /rack-1.5.5/lib/rack/utils.rb:105:in
> `block (2 levels) in parse_nested_query'
<snip> These definitely aren't called from code in unicorn itself.
> /rack-1.5.5/lib/rack/urlmap.rb:50:in
> `each'
> /rack-1.5.5/lib/rack/urlmap.rb:50:in
> `call'
> /unicorn-5.0.1/lib/unicorn/http_server.rb:562:in
> `process_client'
> /unicorn-5.0.1/lib/unicorn/oob_gc.rb:70:in
> `process_client'
> /unicorn-5.0.1/lib/unicorn/http_server.rb:658:in
> `worker_loop'
^ permalink raw reply [relevance 5%]
* Re: Question: How to limit size of log & error files
@ 2015-07-24 14:05 5% ` Ben Lovell
2015-07-24 17:13 8% ` Eric Wong
1 sibling, 0 replies; 27+ results
From: Ben Lovell @ 2015-07-24 14:05 UTC (permalink / raw)
To: Dowd, Stephen; +Cc: unicorn-public@bogomips.org
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 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
>
It's right there in the docs:
http://unicorn.bogomips.org/examples/logrotate.conf
Cheers,
Ben
^ permalink raw reply [relevance 5%]
* Re: Question: How to limit size of log & error files
2015-07-24 14:05 5% ` Ben Lovell
@ 2015-07-24 17:13 8% ` Eric Wong
1 sibling, 0 replies; 27+ results
From: Eric Wong @ 2015-07-24 17:13 UTC (permalink / raw)
To: Dowd, Stephen; +Cc: unicorn-public
"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.
^ permalink raw reply [relevance 8%]
* [PATCH] doc: remove references to old servers
@ 2015-07-15 22:05 1% Eric Wong
0 siblings, 0 replies; 27+ results
From: Eric Wong @ 2015-07-15 22:05 UTC (permalink / raw)
To: unicorn-public
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.
---
Application_Timeouts | 6 +++---
KNOWN_ISSUES | 14 +++++++-------
Links | 30 ++++++++++++++----------------
PHILOSOPHY | 6 ------
README | 32 ++++++++++++++++----------------
Sandbox | 2 +-
TUNING | 10 +++++-----
examples/nginx.conf | 21 ++++++++++-----------
ext/unicorn_http/unicorn_http.rl | 2 +-
lib/unicorn.rb | 6 +++---
lib/unicorn/configurator.rb | 24 ++++++++++--------------
lib/unicorn/http_server.rb | 4 ++--
lib/unicorn/socket_helper.rb | 8 +++-----
lib/unicorn/util.rb | 2 +-
lib/unicorn/worker.rb | 4 ++--
15 files changed, 78 insertions(+), 93 deletions(-)
diff --git a/Application_Timeouts b/Application_Timeouts
index 5f0370d..561a1cc 100644
--- a/Application_Timeouts
+++ b/Application_Timeouts
@@ -4,10 +4,10 @@ This article focuses on _application_ setup for Rack applications, but
can be expanded to all applications that connect to external resources
and expect short response times.
-This article is not specific to \Unicorn, but exists to discourage
+This article is not specific to unicorn, but exists to discourage
the overuse of the built-in
{timeout}[link:Unicorn/Configurator.html#method-i-timeout] directive
-in \Unicorn.
+in unicorn.
== ALL External Resources Are Considered Unreliable
@@ -71,7 +71,7 @@ handle network/server failures.
== The Last Line Of Defense
The {timeout}[link:Unicorn/Configurator.html#method-i-timeout] mechanism
-in \Unicorn is an extreme solution that should be avoided whenever
+in unicorn is an extreme solution that should be avoided whenever
possible. It will help catch bugs in your application where and when
your application forgets to use timeouts, but it is expensive as it
kills and respawns a worker process.
diff --git a/KNOWN_ISSUES b/KNOWN_ISSUES
index 1950223..6b80517 100644
--- a/KNOWN_ISSUES
+++ b/KNOWN_ISSUES
@@ -13,7 +13,7 @@ acceptable solution. Those issues are documented here.
* PRNGs (pseudo-random number generators) loaded before forking
(e.g. "preload_app true") may need to have their internal state
- reset in the after_fork hook. Starting with \Unicorn 3.6.1, we
+ reset in the after_fork hook. Starting with unicorn 3.6.1, we
have builtin workarounds for Kernel#rand and OpenSSL::Random users,
but applications may use other PRNGs.
@@ -36,13 +36,13 @@ acceptable solution. Those issues are documented here.
* Under some versions of Ruby 1.8, it is necessary to call +srand+ in an
after_fork hook to get correct random number generation. We have a builtin
- workaround for this starting with \Unicorn 3.6.1
+ workaround for this starting with unicorn 3.6.1
See http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/36450
* On Ruby 1.8 prior to Ruby 1.8.7-p248, *BSD platforms have a broken
stdio that causes failure for file uploads larger than 112K. Upgrade
- your version of Ruby or continue using Unicorn 1.x/3.4.x.
+ your version of Ruby or continue using unicorn 1.x/3.4.x.
* Under Ruby 1.9.1, methods like Array#shuffle and Array#sample will
segfault if called after forking. Upgrade to Ruby 1.9.2 or call
@@ -53,12 +53,12 @@ acceptable solution. Those issues are documented here.
* Rails 2.3.2 bundles its own version of Rack. This may cause subtle
bugs when simultaneously loaded with the system-wide Rack Rubygem
- which Unicorn depends on. Upgrading to Rails 2.3.4 (or later) is
+ which unicorn depends on. Upgrading to Rails 2.3.4 (or later) is
strongly recommended for all Rails 2.3.x users for this (and security
reasons). Rails 2.2.x series (or before) did not bundle Rack and are
should be unnaffected. If there is any reason which forces your
application to use Rails 2.3.2 and you have no other choice, then
- you may edit your Unicorn gemspec and remove the Rack dependency.
+ you may edit your unicorn gemspec and remove the Rack dependency.
ref: http://mid.gmane.org/20091014221552.GA30624@dcvr.yhbt.net
Note: the workaround described in the article above only made
@@ -71,9 +71,9 @@ acceptable solution. Those issues are documented here.
set :env, :production
set :run, false
Since this is no longer an issue with Sinatra 0.9.x apps, this will not be
- fixed on our end. Since Unicorn is itself the application launcher, the
+ fixed on our end. Since unicorn is itself the application launcher, the
at_exit handler used in old Sinatra always caused Mongrel to be launched
- whenever a Unicorn worker was about to exit.
+ whenever a unicorn worker was about to exit.
Also remember we're capable of replacing the running binary without dropping
any connections regardless of framework :)
diff --git a/Links b/Links
index 5a586c1..ad05afd 100644
--- a/Links
+++ b/Links
@@ -1,13 +1,13 @@
= Related Projects
-If you're interested in \Unicorn, you may be interested in some of the projects
+If you're interested in unicorn, you may be interested in some of the projects
listed below. If you have any links to add/change/remove, please tell us at
mailto:unicorn-public@bogomips.org!
== Disclaimer
-The \Unicorn project is not responsible for the content in these links.
-Furthermore, the \Unicorn project has never, does not and will never endorse:
+The unicorn project is not responsible for the content in these links.
+Furthermore, the unicorn project has never, does not and will never endorse:
* any for-profit entities or services
* any non-{Free Software}[http://www.gnu.org/philosophy/free-sw.html]
@@ -15,13 +15,13 @@ Furthermore, the \Unicorn project has never, does not and will never endorse:
The existence of these links does not imply endorsement of any entities
or services behind them.
-=== For use with \Unicorn
+=== For use with unicorn
* {Bluepill}[https://github.com/arya/bluepill] -
a simple process monitoring tool written in Ruby
* {golden_brindle}[https://github.com/simonoff/golden_brindle] - tool to
- manage multiple \Unicorn instances/applications on a single server
+ manage multiple unicorn instances/applications on a single server
* {raindrops}[http://raindrops.bogomips.org/] - real-time stats for
preforking Rack servers
@@ -29,27 +29,25 @@ or services behind them.
* {UnXF}[http://bogomips.org/unxf/] Un-X-Forward* the Rack environment,
useful since unicorn is designed to be deployed behind a reverse proxy.
-=== \Unicorn is written to work with
+=== unicorn is written to work with
* {Rack}[http://rack.github.io/] - a minimal interface between webservers
supporting Ruby and Ruby frameworks
* {Ruby}[https://www.ruby-lang.org/en/] - the programming language of
- Rack and \Unicorn
+ Rack and unicorn
-* {nginx}[http://nginx.org/] - the reverse proxy for use with \Unicorn
+* {nginx}[http://nginx.org/] - the reverse proxy for use with unicorn
-* {kgio}[http://bogomips.org/kgio/] - the I/O library written for \Unicorn
+* {kgio}[http://bogomips.org/kgio/] - the I/O library written for unicorn
+ (deprecated and functionality being mainlined into Ruby)
=== Derivatives
-* {Green Unicorn}[http://gunicorn.org/] - a Python version of \Unicorn
+* {Green Unicorn}[http://gunicorn.org/] - a Python version of unicorn
-* {Rainbows!}[http://rainbows.bogomips.org/] - \Unicorn for sleepy
- apps and slow clients (historical).
-
-* {yahns}[http://yahns.yhbt.net/] - like Rainbows!, but with fewer options
- and designed for energy efficiency on idle sites.
+* {yahns}[http://yahns.yhbt.net/] - the complete opposite of unicorn in
+ every imaginable way. Designed for energy efficiency on idle sites.
=== Prior Work
@@ -57,4 +55,4 @@ or services behind them.
unicorn is based on
* {david}[http://bogomips.org/david.git] - a tool to explain why you need
- nginx in front of \Unicorn
+ nginx in front of unicorn
diff --git a/PHILOSOPHY b/PHILOSOPHY
index 18b2d82..feb83d9 100644
--- a/PHILOSOPHY
+++ b/PHILOSOPHY
@@ -137,9 +137,3 @@ unicorn is highly inefficient for Comet/reverse-HTTP/push applications
where the HTTP connection spends a large amount of time idle.
Nevertheless, the ease of troubleshooting, debugging, and management of
unicorn may still outweigh the drawbacks for these applications.
-
-The {Rainbows!}[http://rainbows.bogomips.org/] aims to fill the gap for
-odd corner cases where the nginx + unicorn combination is not enough.
-While Rainbows! management/administration is largely identical to
-unicorn, Rainbows! is far more ambitious and has seen little real-world
-usage.
diff --git a/README b/README
index bd626e9..dc121d3 100644
--- a/README
+++ b/README
@@ -1,10 +1,10 @@
-= Unicorn: Rack HTTP server for fast clients and Unix
+= unicorn: Rack HTTP server for fast clients and Unix
-\Unicorn is an HTTP server for Rack applications designed to only serve
+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.
+both the the request and response in between unicorn and slow clients.
== Features
@@ -15,9 +15,9 @@ both the the request and response in between \Unicorn and slow clients.
* Compatible with Ruby 1.9.3 and later.
unicorn 4.8.x will remain supported for Ruby 1.8 users.
-* Process management: \Unicorn will reap and restart workers that
+* Process management: unicorn will reap and restart workers that
die from broken apps. There is no need to manage multiple processes
- or ports yourself. \Unicorn can spawn and manage any number of
+ or ports yourself. unicorn can spawn and manage any number of
worker processes you choose to scale to your backend.
* Load balancing is done entirely by the operating system kernel.
@@ -33,11 +33,11 @@ both the the request and response in between \Unicorn and slow clients.
* Builtin reopening of all log files in your application via
USR1 signal. This allows logrotate to rotate files atomically and
quickly via rename instead of the racy and slow copytruncate method.
- \Unicorn also takes steps to ensure multi-line log entries from one
+ unicorn also takes steps to ensure multi-line log entries from one
request all stay within the same file.
* nginx-style binary upgrades without losing connections.
- You can upgrade \Unicorn, your entire application, libraries
+ You can upgrade unicorn, your entire application, libraries
and even your Ruby interpreter without dropping clients.
* before_fork and after_fork hooks in case your application
@@ -60,15 +60,15 @@ both the the request and response in between \Unicorn and slow clients.
== License
-\Unicorn is copyright 2009 by all contributors (see logs in git).
+unicorn is copyright 2009 by all contributors (see logs in git).
It is based on Mongrel 1.1.5.
Mongrel is copyright 2007 Zed A. Shaw and contributors.
-\Unicorn is licensed under (your choice) of the GPLv2 or later
+unicorn is licensed under (your choice) of the GPLv2 or later
(GPLv3+ preferred), or Ruby (1.8)-specific terms.
See the included LICENSE file for details.
-\Unicorn is 100% Free Software.
+unicorn is 100% Free Software.
== Install
@@ -108,17 +108,17 @@ In RAILS_ROOT, run:
unicorn_rails
-\Unicorn will bind to all interfaces on TCP port 8080 by default.
+unicorn will bind to all interfaces on TCP port 8080 by default.
You may use the +--listen/-l+ switch to bind to a different
address:port or a UNIX socket.
=== Configuration File(s)
-\Unicorn will look for the config.ru file used by rackup in APP_ROOT.
+unicorn will look for the config.ru file used by rackup in APP_ROOT.
-For deployments, it can use a config file for \Unicorn-specific options
+For deployments, it can use a config file for unicorn-specific options
specified by the +--config-file/-c+ command-line switch. See
-Unicorn::Configurator for the syntax of the \Unicorn-specific options.
+Unicorn::Configurator for the syntax of the unicorn-specific options.
The default settings are designed for maximum out-of-the-box
compatibility with existing applications.
@@ -130,7 +130,7 @@ supported. Run `unicorn -h` to see command-line options.
There is NO WARRANTY whatsoever if anything goes wrong, but
{let us know}[link:ISSUES.html] and we'll try our best to fix it.
-\Unicorn is designed to only serve fast clients either on the local host
+unicorn is designed to only serve fast clients either on the local host
or a fast LAN. See the PHILOSOPHY and DESIGN documents for more details
regarding this.
@@ -140,6 +140,6 @@ All feedback (bug reports, user/development dicussion, patches, pull
requests) go to the mailing list/newsgroup. See the ISSUES document for
information on the {mailing list}[mailto:unicorn-public@bogomips.org].
-For the latest on \Unicorn releases, you may also finger us at
+For the latest on unicorn releases, you may also finger us at
unicorn@bogomips.org or check our NEWS page (and subscribe to our Atom
feed).
diff --git a/Sandbox b/Sandbox
index a6c3fe7..997b92f 100644
--- a/Sandbox
+++ b/Sandbox
@@ -1,4 +1,4 @@
-= Tips for using \Unicorn with Sandbox installation tools
+= Tips for using unicorn with Sandbox installation tools
Since unicorn includes executables and is usually used to start a Ruby
process, there are certain caveats to using it with tools that sandbox
diff --git a/TUNING b/TUNING
index 6a6d7db..247090b 100644
--- a/TUNING
+++ b/TUNING
@@ -1,10 +1,10 @@
-= Tuning \Unicorn
+= Tuning unicorn
-\Unicorn performance is generally as good as a (mostly) Ruby web server
+unicorn performance is generally as good as a (mostly) Ruby web server
can provide. Most often the performance bottleneck is in the web
application running on Unicorn rather than Unicorn itself.
-== \Unicorn Configuration
+== unicorn Configuration
See Unicorn::Configurator for details on the config file format.
+worker_processes+ is the most-commonly needed tuning parameter.
@@ -14,7 +14,7 @@ See Unicorn::Configurator for details on the config file format.
* worker_processes should be scaled to the number of processes your
backend system(s) can support. DO NOT scale it to the number of
external network clients your application expects to be serving.
- \Unicorn is NOT for serving slow clients, that is the job of nginx.
+ unicorn is NOT for serving slow clients, that is the job of nginx.
* worker_processes should be *at* *least* the number of CPU cores on
a dedicated server (unless you do not have enough memory).
@@ -58,7 +58,7 @@ See Unicorn::Configurator for details on the config file format.
* UNIX domain sockets are slightly faster than TCP sockets, but only
work if nginx is on the same machine.
-== Other \Unicorn settings
+== Other unicorn settings
* Setting "preload_app true" can allow copy-on-write-friendly GC to
be used to save memory. It will probably not work out of the box with
diff --git a/examples/nginx.conf b/examples/nginx.conf
index a68fe6f..0583c1f 100644
--- a/examples/nginx.conf
+++ b/examples/nginx.conf
@@ -1,5 +1,5 @@
# This is example contains the bare mininum to get nginx going with
-# Unicorn or Rainbows! servers. Generally these configuration settings
+# unicorn servers. Generally these configuration settings
# are applicable to other HTTP application servers (and not just Ruby
# ones), so if you have one working well for proxying another app
# server, feel free to continue using it.
@@ -44,8 +44,8 @@ http {
# click tracking!
access_log /path/to/nginx.access.log combined;
- # you generally want to serve static files with nginx since neither
- # Unicorn nor Rainbows! is optimized for it at the moment
+ # you generally want to serve static files with nginx since
+ # unicorn is not and will never be optimized for it
sendfile on;
tcp_nopush on; # off may be better for *some* Comet/long-poll stuff
@@ -67,10 +67,10 @@ http {
text/javascript application/x-javascript
application/atom+xml;
- # this can be any application server, not just Unicorn/Rainbows!
+ # this can be any application server, not just unicorn
upstream app_server {
# fail_timeout=0 means we always retry an upstream even if it failed
- # to return a good HTTP response (in case the Unicorn master nukes a
+ # to return a good HTTP response (in case the unicorn master nukes a
# single worker for timing out).
# for UNIX domain socket setups:
@@ -132,12 +132,11 @@ http {
# redirects, we set the Host: header above already.
proxy_redirect off;
- # set "proxy_buffering off" *only* for Rainbows! when doing
- # Comet/long-poll/streaming. It's also safe to set if you're using
- # only serving fast clients with Unicorn + nginx, but not slow
- # clients. You normally want nginx to buffer responses to slow
- # clients, even with Rails 3.1 streaming because otherwise a slow
- # client can become a bottleneck of Unicorn.
+ # It's also safe to set if you're using only serving fast clients
+ # with unicorn + nginx, but not slow clients. You normally want
+ # nginx to buffer responses to slow clients, even with Rails 3.1
+ # streaming because otherwise a slow client can become a bottleneck
+ # of unicorn.
#
# The Rack application may also set "X-Accel-Buffering (yes|no)"
# in the response headers do disable/enable buffering on a
diff --git a/ext/unicorn_http/unicorn_http.rl b/ext/unicorn_http/unicorn_http.rl
index a5f069d..046ccb5 100644
--- a/ext/unicorn_http/unicorn_http.rl
+++ b/ext/unicorn_http/unicorn_http.rl
@@ -38,7 +38,7 @@ static VALUE set_maxhdrlen(VALUE self, VALUE len)
return UINT2NUM(MAX_HEADER_LEN = NUM2UINT(len));
}
-/* keep this small for Rainbows! since every client has one */
+/* keep this small for other servers (e.g. yahns) since every client has one */
struct http_parser {
int cs; /* Ragel internal state */
unsigned int flags;
diff --git a/lib/unicorn.rb b/lib/unicorn.rb
index 9fdcb8e..b0e6bd1 100644
--- a/lib/unicorn.rb
+++ b/lib/unicorn.rb
@@ -10,10 +10,10 @@ require 'kgio'
# enough functionality to service web application requests fast as possible.
# :startdoc:
-# \Unicorn exposes very little of an user-visible API and most of its
-# internals are subject to change. \Unicorn is designed to host Rack
+# unicorn exposes very little of an user-visible API and most of its
+# internals are subject to change. unicorn is designed to host Rack
# applications, so applications should be written against the Rack SPEC
-# and not \Unicorn internals.
+# and not unicorn internals.
module Unicorn
# Raised inside TeeInput when a client closes the socket inside the
diff --git a/lib/unicorn/configurator.rb b/lib/unicorn/configurator.rb
index 02f6b6b..4da19bb 100644
--- a/lib/unicorn/configurator.rb
+++ b/lib/unicorn/configurator.rb
@@ -1,7 +1,7 @@
# -*- encoding: binary -*-
require 'logger'
-# Implements a simple DSL for configuring a \Unicorn server.
+# Implements a simple DSL for configuring a unicorn server.
#
# See http://unicorn.bogomips.org/examples/unicorn.conf.rb and
# http://unicorn.bogomips.org/examples/unicorn.conf.minimal.rb
@@ -282,20 +282,19 @@ class Unicorn::Configurator
# Setting this to +true+ can make streaming responses in Rails 3.1
# appear more quickly at the cost of slightly higher bandwidth usage.
# The effect of this option is most visible if nginx is not used,
- # but nginx remains highly recommended with \Unicorn.
+ # but nginx remains highly recommended with unicorn.
#
# This has no effect on UNIX sockets.
#
- # Default: +true+ (Nagle's algorithm disabled) in \Unicorn,
- # +true+ in Rainbows! This defaulted to +false+ in \Unicorn
- # 3.x
+ # Default: +true+ (Nagle's algorithm disabled) in unicorn
+ # This defaulted to +false+ in unicorn 3.x
#
# [:tcp_nopush => true or false]
#
# Enables/disables TCP_CORK in Linux or TCP_NOPUSH in FreeBSD
#
# This prevents partial TCP frames from being sent out and reduces
- # wakeups in nginx if it is on a different machine. Since \Unicorn
+ # wakeups in nginx if it is on a different machine. Since unicorn
# is only designed for applications that send the response body
# quickly without keepalive, sockets will always be flushed on close
# to prevent delays.
@@ -303,7 +302,7 @@ class Unicorn::Configurator
# This has no effect on UNIX sockets.
#
# Default: +false+
- # This defaulted to +true+ in \Unicorn 3.4 - 3.7
+ # This defaulted to +true+ in unicorn 3.4 - 3.7
#
# [:ipv6only => true or false]
#
@@ -387,12 +386,10 @@ class Unicorn::Configurator
# and +false+ or +nil+ is synonymous for a value of zero.
#
# A value of +1+ is a good optimization for local networks
- # and trusted clients. For Rainbows! and Zbatery users, a higher
- # value (e.g. +60+) provides more protection against some
- # denial-of-service attacks. There is no good reason to ever
- # disable this with a +zero+ value when serving HTTP.
+ # and trusted clients. There is no good reason to ever
+ # disable this with a +zero+ value with unicorn.
#
- # Default: 1 retransmit for \Unicorn, 60 for Rainbows! 0.95.0\+
+ # Default: 1
#
# [:accept_filter => String]
#
@@ -401,8 +398,7 @@ class Unicorn::Configurator
# This enables either the "dataready" or (default) "httpready"
# accept() filter under FreeBSD. This is intended as an
# optimization to reduce context switches with common GET/HEAD
- # requests. For Rainbows! and Zbatery users, this provides
- # some protection against certain denial-of-service attacks, too.
+ # requests.
#
# There is no good reason to change from the default.
#
diff --git a/lib/unicorn/http_server.rb b/lib/unicorn/http_server.rb
index 0f97516..3dbfd3e 100644
--- a/lib/unicorn/http_server.rb
+++ b/lib/unicorn/http_server.rb
@@ -7,8 +7,8 @@
#
# Users do not need to know the internals of this class, but reading the
# {source}[http://bogomips.org/unicorn.git/tree/lib/unicorn/http_server.rb]
-# is education for programmers wishing to learn how \Unicorn works.
-# See Unicorn::Configurator for information on how to configure \Unicorn.
+# is education for programmers wishing to learn how unicorn works.
+# See Unicorn::Configurator for information on how to configure unicorn.
class Unicorn::HttpServer
# :stopdoc:
attr_accessor :app, :timeout, :worker_processes,
diff --git a/lib/unicorn/socket_helper.rb b/lib/unicorn/socket_helper.rb
index 812ac53..df8315e 100644
--- a/lib/unicorn/socket_helper.rb
+++ b/lib/unicorn/socket_helper.rb
@@ -5,14 +5,12 @@ require 'socket'
module Unicorn
module SocketHelper
- # internal interface, only used by Rainbows!/Zbatery
+ # internal interface
DEFAULTS = {
# The semantics for TCP_DEFER_ACCEPT changed in Linux 2.6.32+
# with commit d1b99ba41d6c5aa1ed2fc634323449dd656899e9
- # This change shouldn't affect Unicorn users behind nginx (a
- # value of 1 remains an optimization), but Rainbows! users may
- # want to use a higher value on Linux 2.6.32+ to protect against
- # denial-of-service attacks
+ # This change shouldn't affect unicorn users behind nginx (a
+ # value of 1 remains an optimization).
:tcp_defer_accept => 1,
# FreeBSD, we need to override this to 'dataready' if we
diff --git a/lib/unicorn/util.rb b/lib/unicorn/util.rb
index c7784bd..2f8bfeb 100644
--- a/lib/unicorn/util.rb
+++ b/lib/unicorn/util.rb
@@ -1,7 +1,7 @@
# -*- encoding: binary -*-
require 'fcntl'
-module Unicorn::Util
+module Unicorn::Util # :nodoc:
# :stopdoc:
def self.is_log?(fp)
diff --git a/lib/unicorn/worker.rb b/lib/unicorn/worker.rb
index b3f8afe..6748a2f 100644
--- a/lib/unicorn/worker.rb
+++ b/lib/unicorn/worker.rb
@@ -3,8 +3,8 @@ require "raindrops"
# This class and its members can be considered a stable interface
# and will not change in a backwards-incompatible fashion between
-# releases of \Unicorn. Knowledge of this class is generally not
-# not needed for most users of \Unicorn.
+# releases of unicorn. Knowledge of this class is generally not
+# not needed for most users of unicorn.
#
# Some users may want to access it in the before_fork/after_fork hooks.
# See the Unicorn::Configurator RDoc for examples.
--
EW
^ permalink raw reply related [relevance 1%]
* Re: On USR2, new master runs with same PID
@ 2015-03-20 2:08 5% ` Eric Wong
0 siblings, 0 replies; 27+ results
From: Eric Wong @ 2015-03-20 2:08 UTC (permalink / raw)
To: Kevin Yank; +Cc: unicorn-public
Kevin Yank <kyank@avalanche.com.au> wrote:
> Regarding zero-downtime deploys:
>
> On 12 Mar 2015, at 5:45 pm, Eric Wong <e@80x24.org> wrote:
>
> > Best bet would be to run with double the workers temporarily unless
> > you're too low on memory (and swapping) or backend (DB) connections or
> > any other resource.
>
> I’d like to take this approach as I do have enough memory to spare.
> How do you usually implement this? Any good write-ups or sample
> configs you can point me to?
Only send SIGUSR2 to the master, leaving you with two masters and two
sets of workers. Skip (automated) sending of SIGTTOU signals to lower
worker count to the old master.
Eventually, you'll decide to send SIGQUIT to the old master to stop
it (or the new one, if you decide the new code is broken).
You can still combine this with SIGWINCH (or SIGTTOU) to stop traffic
flow to the old master, too.
Thanks for following up on your logrotate/eye issue, by the way.
^ permalink raw reply [relevance 5%]
* Re: On USR2, new master runs with same PID
@ 2015-03-20 1:55 5% ` Kevin Yank
1 sibling, 0 replies; 27+ results
From: Kevin Yank @ 2015-03-20 1:55 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn-public
[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]
> On 12 Mar 2015, at 5:45 pm, Eric Wong <e@80x24.org> wrote:
>
> Kevin Yank <kyank@avalanche.com.au> wrote:
>> It’s possible; I’m using eye (https://github.com/kostya/eye) as a
>
> Aha! I forgot about that one, try upgrading to unicorn 4.8.3 which
> fixed this issue last year. ref:
>
> http://bogomips.org/unicorn-public/m/20140504023338.GA583@dcvr.yhbt.net.html
> http://bogomips.org/unicorn-public/m/20140502231558.GA4215@dcvr.yhbt.net.html
Finally solved this definitively. It was user error to do with my setup of the eye process monitor.
I’d accidentally deployed a buggy logrotate configuration for eye, which was causing a second eye daemon to be spawned once a day (when the logs were rotated). Those two eye daemons ran side-by-side, and fought with each other when one was told to restart Unicorn. I’d already anticipated and fixed this problem, but failed to deploy the correct version of the config to our cluster.
All fixed now. Thanks for your pointers; they put me on the right track. :)
--
Kevin Yank
Chief Technology Officer, Avalanche Technology Group
http://avalanche.com.au/
ph: +61 4 2241 0083
^ permalink raw reply [relevance 5%]
* Re: Struggling with logrotate and unicorn
2011-04-12 18:59 5% ` Eric Wong
@ 2011-04-12 22:38 5% ` Emmanuel Gomez
2011-04-12 22:51 5% ` Eric Wong
0 siblings, 1 reply; 27+ results
From: Emmanuel Gomez @ 2011-04-12 22:38 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
On Apr 12, 2011, at 11:59 AM, Eric Wong wrote:
> I'll make that more robust and release
> 3.6.0 sometime this week with (hopefully) a few other minor
> improvements.
Great. This is apparently an infrequent circumstance (uncommon configuration?), but there will be a next person who does this (or comparable silliness).
>> Thanks for your reply, I'm off to comment on the GitHub blog post to
>> try to warn others to use Unicorn::Worker#user instead of the example
>> code in after_fork.
>
> Thanks, that seems to be a general problem with people relying on
> blog/mailing list posts instead of consistently updated documentation.
Indeed, but I read most of the unicorn docs, and examples/unicorn.conf.rb in 3.3.1 doesn't mention Unicorn::Worker#user, so I remained unaware until I read through worker.rb.
Hey, I can help here. Here's a patch:
>From de3178d98c81de3c8765cebd579ef3f7dd4b2d64 Mon Sep 17 00:00:00 2001
From: Emmanuel Gomez <emmanuel.gomez@gmail.com>
Date: Tue, 12 Apr 2011 15:36:36 -0700
Subject: [PATCH] Document Unicorn::Worker#user in example unicorn conf.
---
examples/unicorn.conf.rb | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/examples/unicorn.conf.rb b/examples/unicorn.conf.rb
index 28a9e65..8b7ad47 100644
--- a/examples/unicorn.conf.rb
+++ b/examples/unicorn.conf.rb
@@ -84,4 +84,8 @@ after_fork do |server, worker|
# and Redis. TokyoCabinet file handles are safe to reuse
# between any number of forked children (assuming your kernel
# correctly implements pread()/pwrite() system calls)
+
+ # if running the master process as root and the workers as an unprivileged
+ # user, do this to switch euid/egid in the workers (also chowns logs):
+ # worker.user("unprivileged_user", "unprivileged_group")
end
--
1.7.3.4
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 5%]
* Re: Struggling with logrotate and unicorn
2011-04-12 22:38 5% ` Emmanuel Gomez
@ 2011-04-12 22:51 5% ` Eric Wong
2011-04-12 23:01 6% ` Emmanuel Gomez
0 siblings, 1 reply; 27+ results
From: Eric Wong @ 2011-04-12 22:51 UTC (permalink / raw)
To: unicorn list; +Cc: Emmanuel Gomez
Emmanuel Gomez <emmanuel.gomez@gmail.com> wrote:
> On Apr 12, 2011, at 11:59 AM, Eric Wong wrote:
> > I'll make that more robust and release 3.6.0 sometime this week with
> > (hopefully) a few other minor improvements.
>
> Great. This is apparently an infrequent circumstance (uncommon
> configuration?), but there will be a next person who does this (or
> comparable silliness).
Yes, I think most people still deploy and start as non-root
(Capistrano/Vlad). But I also distribute init scripts and those
are usually run as root :x
> >> Thanks for your reply, I'm off to comment on the GitHub blog post
> >> to try to warn others to use Unicorn::Worker#user instead of the
> >> example code in after_fork.
> >
> > Thanks, that seems to be a general problem with people relying on
> > blog/mailing list posts instead of consistently updated
> > documentation.
>
> Indeed, but I read most of the unicorn docs, and
> examples/unicorn.conf.rb in 3.3.1 doesn't mention
> Unicorn::Worker#user, so I remained unaware until I read through
> worker.rb.
Actually the (usually) user-visible one should be
Unicorn::Configurator#user which should be in the top-level.
Worker#user is just the internal call.
> Hey, I can help here. Here's a patch:
Perhaps this is better? I added a blurb discouraging people from
running as root in the first place. You'll still get credit :)
>From c4d3cd7d7b32ed133e25e3740c8e7a3493592eec Mon Sep 17 00:00:00 2001
From: Emmanuel Gomez <emmanuel.gomez@gmail.com>
Date: Tue, 12 Apr 2011 15:36:36 -0700
Subject: [PATCH] Document "user" directive in example unicorn conf
---
examples/unicorn.conf.rb | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/examples/unicorn.conf.rb b/examples/unicorn.conf.rb
index 28a9e65..61f0b4b 100644
--- a/examples/unicorn.conf.rb
+++ b/examples/unicorn.conf.rb
@@ -12,6 +12,13 @@
# more will usually help for _short_ waits on databases/caches.
worker_processes 4
+# Since Unicorn is never exposed to outside clients, it does not need to
+# run on the standard HTTP port (80), there is no reason to start Unicorn
+# as root unless it's from system init scripts.
+# If running the master process as root and the workers as an unprivileged
+# user, do this to switch euid/egid in the workers (also chowns logs):
+# user "unprivileged_user", "unprivileged_group"
+
# Help ensure your application will always spawn in the symlinked
# "current" directory that Capistrano sets up.
working_directory "/path/to/app/current" # available in 0.94.0+
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 5%]
* Re: Struggling with logrotate and unicorn
2011-04-12 22:51 5% ` Eric Wong
@ 2011-04-12 23:01 6% ` Emmanuel Gomez
0 siblings, 0 replies; 27+ results
From: Emmanuel Gomez @ 2011-04-12 23:01 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
On Apr 12, 2011, at 3:51 PM, Eric Wong wrote:
> Yes, I think most people still deploy and start as non-root
> (Capistrano/Vlad). But I also distribute init scripts and those
> are usually run as root :x
And it's because of init scripts that I'm running unicorn as root.
> Actually the (usually) user-visible one should be
> Unicorn::Configurator#user which should be in the top-level.
> Worker#user is just the internal call.
Oh, great, I'm glad you pointed that out. Since the worker instance is yielded into the after_fork block, I started looking there. I'll update my config to use the public interface. Also, I'll go correct my github blog post comment, oops.
>> Hey, I can help here. Here's a patch:
>
> Perhaps this is better? I added a blurb discouraging people from
> running as root in the first place.
Looks great.
> You'll still get credit :)
It's a nothing, I don't need any credit :)
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 6%]
* Re: Struggling with logrotate and unicorn
2011-04-12 17:58 6% ` Eric Wong
@ 2011-04-12 18:36 5% ` Emmanuel Gomez
2011-04-12 18:59 5% ` Eric Wong
0 siblings, 1 reply; 27+ results
From: Emmanuel Gomez @ 2011-04-12 18:36 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn list
On Apr 12, 2011, at 10:58 AM, Eric Wong wrote:
> Emmanuel Gomez <emmanuel.gomez@gmail.com> wrote:
>> I have confirmed that logrotate creates the logs with a 0600 umask and
>> the uid/gid of my unprivileged user (per my logrotate config, loosely
>> based on the example logrotate.conf from 3.4 or 3.5).
>
> Did the permissions of the old (rotated) log files change?
No, they remained owned by root.
>> The problem occurs when I send a USR1 signal to the master process (as
>> root, because the master is running as root) after the logs have been
>> rotated. As near as I can tell, after that the Unicorn master chowns
>> the logs to root ownership. Then, the workers attempt to chown the
>> logs back to ownership by the unprivileged user, which repeatedly
>> fails, spewing megabytes of errors that look like:
>
> The rotation error handling should probably just exit! the worker
> and rely on the master to restart it...
That would probably be better behavior, although in this specific case the worker would immediately die on respawn because the log is still owned by root and unwriteable by my unprivileged user.
I did find a resolution: in the after_fork block, I had copied the code to switch users from the GitHub blog post on unicorn (https://github.com/blog/517-unicorn). I didn't see Unicorn::Worker#user, which implements the same code with the addition of a call to Unicorn::Util.chown_logs. When I replace the inline GitHub-blog-derived code with a call to Unicorn::Worker#user, it works.
My understanding is that this (after_fork/Unicorn::Util.chown_logs) shouldn't be executed on USR1; I don't see how the Unicorn::Util.chown_logs call on after_fork (startup) would make a difference w/r/t rotation (much later), but my understanding is obviously incomplete, because it works.
Thanks for your reply, I'm off to comment on the GitHub blog post to try to warn others to use Unicorn::Worker#user instead of the example code in after_fork.
-- Emmanuel
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 5%]
* Re: Struggling with logrotate and unicorn
2011-04-12 18:36 5% ` Emmanuel Gomez
@ 2011-04-12 18:59 5% ` Eric Wong
2011-04-12 22:38 5% ` Emmanuel Gomez
0 siblings, 1 reply; 27+ results
From: Eric Wong @ 2011-04-12 18:59 UTC (permalink / raw)
To: unicorn list; +Cc: Emmanuel Gomez
Emmanuel Gomez <emmanuel.gomez@gmail.com> wrote:
> On Apr 12, 2011, at 10:58 AM, Eric Wong wrote:
> > Emmanuel Gomez <emmanuel.gomez@gmail.com> wrote:
> >> I have confirmed that logrotate creates the logs with a 0600 umask
> >> and the uid/gid of my unprivileged user (per my logrotate config,
> >> loosely based on the example logrotate.conf from 3.4 or 3.5).
> >
> > Did the permissions of the old (rotated) log files change?
>
> No, they remained owned by root.
Remained owned by root? Yes that sounds like the problem.
> >> The problem occurs when I send a USR1 signal to the master process
> >> (as root, because the master is running as root) after the logs
> >> have been rotated. As near as I can tell, after that the Unicorn
> >> master chowns the logs to root ownership. Then, the workers attempt
> >> to chown the logs back to ownership by the unprivileged user, which
> >> repeatedly fails, spewing megabytes of errors that look like:
> >
> > The rotation error handling should probably just exit! the worker
> > and rely on the master to restart it...
>
> That would probably be better behavior, although in this specific case
> the worker would immediately die on respawn because the log is still
> owned by root and unwriteable by my unprivileged user.
>
> I did find a resolution: in the after_fork block, I had copied the
> code to switch users from the GitHub blog post on unicorn
> (https://github.com/blog/517-unicorn). I didn't see
> Unicorn::Worker#user, which implements the same code with the addition
> of a call to Unicorn::Util.chown_logs. When I replace the inline
> GitHub-blog-derived code with a call to Unicorn::Worker#user, it
> works.
Yes, the old versions of Unicorn didn't change users at all.
I always knew user-switching is a pain in the ass to deal with due to
issues like this. Due to work on Rainbows! (designed to run on port
80) and users starting as root anyways (due to init scripts), I needed
add this feature.
> My understanding is that this (after_fork/Unicorn::Util.chown_logs)
> shouldn't be executed on USR1; I don't see how the
> Unicorn::Util.chown_logs call on after_fork (startup) would make a
> difference w/r/t rotation (much later), but my understanding is
> obviously incomplete, because it works.
It's the rotation that attempts to chown since it thinks (incorrectly)
that it's in the master process. I'll make that more robust and release
3.6.0 sometime this week with (hopefully) a few other minor
improvements.
> Thanks for your reply, I'm off to comment on the GitHub blog post to
> try to warn others to use Unicorn::Worker#user instead of the example
> code in after_fork.
Thanks, that seems to be a general problem with people relying on
blog/mailing list posts instead of consistently updated documentation.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 5%]
* Re: Struggling with logrotate and unicorn
2011-04-12 16:13 10% Struggling with logrotate and unicorn Emmanuel Gomez
@ 2011-04-12 17:58 6% ` Eric Wong
2011-04-12 18:36 5% ` Emmanuel Gomez
0 siblings, 1 reply; 27+ results
From: Eric Wong @ 2011-04-12 17:58 UTC (permalink / raw)
To: unicorn list; +Cc: Emmanuel Gomez
Emmanuel Gomez <emmanuel.gomez@gmail.com> wrote:
> I have confirmed that logrotate creates the logs with a 0600 umask and
> the uid/gid of my unprivileged user (per my logrotate config, loosely
> based on the example logrotate.conf from 3.4 or 3.5).
Did the permissions of the old (rotated) log files change?
> The problem occurs when I send a USR1 signal to the master process (as
> root, because the master is running as root) after the logs have been
> rotated. As near as I can tell, after that the Unicorn master chowns
> the logs to root ownership. Then, the workers attempt to chown the
> logs back to ownership by the unprivileged user, which repeatedly
> fails, spewing megabytes of errors that look like:
The rotation error handling should probably just exit! the worker
and rely on the master to restart it...
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 6%]
* Struggling with logrotate and unicorn
@ 2011-04-12 16:13 10% Emmanuel Gomez
2011-04-12 17:58 6% ` Eric Wong
0 siblings, 1 reply; 27+ results
From: Emmanuel Gomez @ 2011-04-12 16:13 UTC (permalink / raw)
To: mongrel-unicorn
Hi,
First of all, thanks for Unicorn, it's a fantastic tool.
I'm starting a Unicorn 3.3.1 master process as root on an Ubuntu 10.04 LTS host, and dropping to an unprivileged user in the workers after forking. This all works fine.
I have confirmed that logrotate creates the logs with a 0600 umask and the uid/gid of my unprivileged user (per my logrotate config, loosely based on the example logrotate.conf from 3.4 or 3.5).
The problem occurs when I send a USR1 signal to the master process (as root, because the master is running as root) after the logs have been rotated. As near as I can tell, after that the Unicorn master chowns the logs to root ownership. Then, the workers attempt to chown the logs back to ownership by the unprivileged user, which repeatedly fails, spewing megabytes of errors that look like:
worker=0 reopening logs...
Unhandled listen loop exception #<Errno::EPERM: Operation not permitted - /opt/wp/src/nascar/current/log/staging.log>.
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/lib/unicorn/util.rb:57:in `chown'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/lib/unicorn/util.rb:57:in `reopen_logs'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/lib/unicorn/util.rb:37:in `each'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/lib/unicorn/util.rb:37:in `reopen_logs'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/lib/unicorn/http_server.rb:569:in `reopen_worker_logs'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/lib/unicorn/http_server.rb:592:in `worker_loop'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/lib/unicorn/http_server.rb:496:in `spawn_missing_workers'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/lib/unicorn/http_server.rb:493:in `fork'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/lib/unicorn/http_server.rb:493:in `spawn_missing_workers'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/lib/unicorn/http_server.rb:489:in `each'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/lib/unicorn/http_server.rb:489:in `spawn_missing_workers'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/lib/unicorn/http_server.rb:503:in `maintain_worker_count'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/lib/unicorn/http_server.rb:297:in `join'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/lib/unicorn.rb:13:in `run'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/gems/unicorn-3.3.1/bin/unicorn_rails:208
/opt/wp/src/nascar/shared/bundle/ruby/1.8/bin/unicorn_rails:19:in `load'
/opt/wp/src/nascar/shared/bundle/ruby/1.8/bin/unicorn_rails:19
I looked at Unicorn::Util.reopen_logs, which is where the exception originates, and clearly has code intended to deal with this (https://github.com/defunkt/unicorn/blob/v3.3.1/lib/unicorn/util.rb#L56), but it doesn't appear to be doing the right thing in my circumstance. It's not apparent to me at a glance why this is failing.
I'm not subscribed to the list, so please cc: my on replies.
Thanks for any input you may have,
Emmanuel Gomez
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 10%]
* Re: Reopening logs - why no relative paths?
@ 2011-04-01 23:15 5% ` Eric Wong
0 siblings, 0 replies; 27+ results
From: Eric Wong @ 2011-04-01 23:15 UTC (permalink / raw)
To: unicorn list
Eric Wong <normalperson@yhbt.net> wrote:
> Matthew Kocher <mkocher@pivotallabs.com> wrote:
> > We just spend a couple hours trying to figure out why sending a USR1
> > signal wasn't causing unicorn to reopen logs. Looking at the source
> > reveals that only files opened with absolute paths are eligible for
> > rotation, the others are silently skipped.
> >
> > We use the fairly standard practice of always logging to
> > log/unicorn.error.log and creating symlinks to where we'd like the
> > logs to live on individual hosts. We'll change our configs for the
> > time being, but is there a reason to not reopen the relative paths?
>
> It's ambiguous due to directory changes[1]. It may be easier now that
> we have the "working_directory" directive now, but configuration changes
> also change (or unset) the "working_directory" which adds to the
> confusion.
>
> We could try allowing it and see what happens, I suppose...
Just pushed this out, thinking about it more I don't think it'll have an
adverse effect on most installations out there...
>From 6647dcb3afa4c0b16c5fef5bfdf88292e6adf6ca Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Fri, 1 Apr 2011 16:09:03 -0700
Subject: [PATCH] util: allow relative paths to be rotated
Users keep both pieces if it's broken :)
---
lib/unicorn/util.rb | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/lib/unicorn/util.rb b/lib/unicorn/util.rb
index 82329eb..cde2563 100644
--- a/lib/unicorn/util.rb
+++ b/lib/unicorn/util.rb
@@ -8,7 +8,6 @@ module Unicorn::Util
! fp.closed? &&
fp.sync &&
- fp.path[0] == ?/ &&
(fp.fcntl(Fcntl::F_GETFL) & append_flags) == append_flags
rescue IOError, Errno::EBADF
false
@@ -25,10 +24,12 @@ module Unicorn::Util
# using logrotate(8) (without copytruncate) or similar tools.
# A +File+ object is considered for reopening if it is:
# 1) opened with the O_APPEND and O_WRONLY flags
- # 2) opened with an absolute path (starts with "/")
- # 3) the current open file handle does not match its original open path
- # 4) unbuffered (as far as userspace buffering goes, not O_SYNC)
+ # 2) the current open file handle does not match its original open path
+ # 3) unbuffered (as far as userspace buffering goes, not O_SYNC)
# Returns the number of files reopened
+ #
+ # In Unicorn 3.5.x and earlier, files must be opened with an absolute
+ # path to be considered a log file.
def self.reopen_logs
to_reopen = []
nr = 0
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 5%]
* [PATCH] add examples/logrotate.conf
2011-03-29 16:24 8% ` Eric Wong
@ 2011-03-29 16:54 29% ` Eric Wong
0 siblings, 0 replies; 27+ results
From: Eric Wong @ 2011-03-29 16:54 UTC (permalink / raw)
To: David Nghiem; +Cc: unicorn list
Eric Wong <normalperson@yhbt.net> wrote:
> That could be it. logrotate (without the scary/expensive
> "copytruncate" option) works very quickly for individual files. Do you
> have the "sharedscripts" option in logrotate enabled? You should enable
> "sharedscripts"
I actually went with lastaction in my example (I keep forgetting it over
the years and going to postrotate + sharedscripts for some reason..)
> I should post a logrotate example config so other users don't run into
> the same problem...
http://unicorn.bogomips.org/examples/logrotate.conf and pushed
this out to unicorn.git
>From c1ebb313735a280582d87c1ba44619aa47e00b06 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Tue, 29 Mar 2011 09:47:26 -0700
Subject: [PATCH] add examples/logrotate.conf
logrotate is the de facto tool for logrotation, so an
example config for highlighting important parts are in order.
Since our USR1 signal handling is part of the crusade against
the slow and lossy "copytruncate" option, be sure to
emphasize that :)
---
examples/logrotate.conf | 29 +++++++++++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
create mode 100644 examples/logrotate.conf
diff --git a/examples/logrotate.conf b/examples/logrotate.conf
new file mode 100644
index 0000000..03fefc6
--- /dev/null
+++ b/examples/logrotate.conf
@@ -0,0 +1,29 @@
+# example logrotate config file, I usually keep this in
+# /etc/logrotate.d/unicorn_app on my Debian systems
+#
+# See the logrotate(8) manpage for more information:
+# http://linux.die.net/man/8/logrotate
+
+# Modify the following glob to match the logfiles your app writes to:
+/var/log/unicorn_app/*.log {
+ # this first block is mostly just personal preference, though
+ # I wish logrotate offered an "hourly" option...
+ daily
+ missingok
+ rotate 180
+ compress # must use with delaycompress below
+ dateext
+
+ # this is important if using "compress" since we need to call
+ # the "lastaction" script below before compressing:
+ delaycompress
+
+ # note the lack of the evil "copytruncate" option in this
+ # config. Unicorn supports the USR1 signal and we send it
+ # as our "lastaction" action:
+ lastaction
+ # assuming your pid file is in /var/run/unicorn_app/pid
+ pid=/var/run/unicorn_app/pid
+ test -s $pid && kill -USR1 "$(cat $pid)"
+ endscript
+}
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply related [relevance 29%]
* Re: unicorn 1.1.x never-ending listen loop IOError exceptions
[not found] ` <AANLkTim3xZMKxcmQzPjcB7vrJKiHoc2f8WoU8RatrDum@mail.gmail.com>
@ 2011-03-29 16:24 8% ` Eric Wong
2011-03-29 16:54 29% ` [PATCH] add examples/logrotate.conf Eric Wong
0 siblings, 1 reply; 27+ results
From: Eric Wong @ 2011-03-29 16:24 UTC (permalink / raw)
To: David Nghiem; +Cc: unicorn list
David Nghiem <david@zendesk.com> wrote:
> I'm wondering if the problem is three logs for unicorn (unicorn.log, and the
> stdout, stderr logs) are rotated by logrotate, but the first log triggers
> the USR1 and in the middle of rotating the remaining logs, the unicorn log
> reopening gets confused.
>
> I'll make it so the USR1 signal is sent after all three logs have been
> rotated. Let this run for a couple months and report back.
That could be it. logrotate (without the scary/expensive
"copytruncate" option) works very quickly for individual files. Do you
have the "sharedscripts" option in logrotate enabled? You should enable
"sharedscripts"
I should post a logrotate example config so other users don't run into
the same problem...
> Thanks, Eric, for your help. I've been running unicorn since the pre-1.0
> days and it's my favorite ruby software.
Good to know!
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 8%]
* Re: unicorn 1.1.x never-ending listen loop IOError exceptions
@ 2011-03-23 0:04 7% ` David Nghiem
0 siblings, 1 reply; 27+ results
From: David Nghiem @ 2011-03-23 0:04 UTC (permalink / raw)
To: unicorn list
On Tue, Mar 22, 2011 at 2:39 PM, Eric Wong <normalperson@yhbt.net> wrote:
>> I don't get any other exceptions. I've found other people have this
>> "IOError: closed stream" error coupled with "Errno::EMFILE" but we
>> have plenty of file-descriptors left.
>
> No Errno::EBADF errors at all?
I didn't check before or after the block of Errno::IOError errors,
there were enough IOError logs to fill up 40gb of disk. I'll capture
the entire deleted log next time.
> <snip> It looks like log reopening failed, below:
>
>> ruby 15209 zendesk 1w REG 252,0 0
>> 3015360 /data/zendesk/log/unicorn.stdout.log
>> ruby 15209 zendesk 2w REG 252,0 24585
>> 3015203 /data/zendesk/log/unicorn.stderr.log-20110110 (deleted)
>> ruby 15209 zendesk 3w REG 252,0 61617590073
>> 3015097 /data/zendesk/log/unicorn.log-20110110 (deleted)
>
> Permissions issue during log rotation? Are you doing "killall -USR1
> unicorn" by any chance or sending a bunch of USR1 signals faster than
> unicorn can process them?
>
> Try just sending one USR1 to the master process and letting the master
> signal the workers.
We rotate logs once a night using logrotate. There's a post-rotate
hook that sends USR1 once to the master. There are three log files
but logrotate is run with the sharedscripts option so only one hook
runs. The log dirs and unicorn processes are run as the same non-root
user.
I'll run an lsof on the healthy workers next time to see if they have
the same deleted log file descriptors.
Are the IOError exceptions and failure to rotate logs related? My
wild guess was this specific worker's unix socket got corrupted
somehow.
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 7%]
* Re: Issue when sending USR2 too soon
2010-01-18 11:43 0% ` Eric Wong
@ 2010-01-18 11:48 0% ` Iñaki Baz Castillo
0 siblings, 0 replies; 27+ results
From: Iñaki Baz Castillo @ 2010-01-18 11:48 UTC (permalink / raw)
To: mongrel-unicorn
El Lunes, 18 de Enero de 2010, Eric Wong escribió:
> On systems with RubyGems, the executable is always an automatically
> generated wrapper script that does "require 'rubygems'" first.
True, but I use Ruby 1.9 which doesn't require using "rubygems". However it's
of course true that the binary does a "gem_load_bin('unicorn'..)" and so.
But in my case, for now, I use directly the *real* executable rather than the
executable that Gem puts in /usr/bin or /usr/local/bin.
> > > Is the issue with a script reading the pid file and sending the signal
> > > because it exists?
> >
> > I've done a init script to start/stop/reload/log-rotate Unicorn. The
> > action "log-rotate" takes the PID from the pid file and sends a USR1
> > (this call is made by logrotate). The action "reload" sends a USR2 and
> > later a TERM (depending on if the PID has changed or not).
> >
> > I just want to avoid that, in case a user invokes "reload" twice too
> > fast, Unicorn receives USR2 before preparing it so it dies. With my
> > "hack" is more difficult such possibility to occur.
>
> I'll look into what the consequences of writing the pid file after
> signal handlers are setup later this week.
Hum, yes, that sound good.
> Unfortunately pid files are inherently racy for the USR2 case. Perhaps
> your script can check the ctime of the pid file...
Good suggestion :)
--
Iñaki Baz Castillo <ibc@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Issue when sending USR2 too soon
2010-01-18 11:25 5% ` Iñaki Baz Castillo
@ 2010-01-18 11:43 0% ` Eric Wong
2010-01-18 11:48 0% ` Iñaki Baz Castillo
0 siblings, 1 reply; 27+ results
From: Eric Wong @ 2010-01-18 11:43 UTC (permalink / raw)
To: unicorn list
Iñaki Baz Castillo <ibc@aliax.net> wrote:
> El Lunes, 18 de Enero de 2010, Eric Wong escribió:
> > Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > > El Domingo, 17 de Enero de 2010, Iñaki Baz Castillo escribió:
> > > > What about if Unicorn very quicky prepares the trap for USR2 so in case
> > > > it receives it soon when starting it ignores it (and logs some
> > > > warning)? Does it make sense?
> > >
> > > Adding the following on the top of bin/unicorn solves the problem:
> > >
> > > # Ignore USR2 (instead of terminating script) in case it arrives too
> > > soon. trap("USR2") do
> > > $stderr.puts "WARN: USR2 signal (reload action) received too soon,
> > > ignored" end
> >
> > No it doesn't, it just reduces the window where signals aren't setup.
> > On systems where Unicorn is installed as a RubyGem, that window of time
> > may be much bigger.
>
> But note that I've added:
>
> trap("USR2") do
> $stderr.puts "WARN: USR2 signal (reload action) received too soon,
> ignored"
> end
>
> at the beginning of the executable, so the time window is really reduced. Also
> note that in my modified version of the executable I load many other gems and
> them make the unicorn loading slower, increasing the time window.
On systems with RubyGems, the executable is always an automatically
generated wrapper script that does "require 'rubygems'" first.
> > Is the issue with a script reading the pid file and sending the signal
> > because it exists?
>
> I've done a init script to start/stop/reload/log-rotate Unicorn. The action
> "log-rotate" takes the PID from the pid file and sends a USR1 (this call is
> made by logrotate). The action "reload" sends a USR2 and later a TERM
> (depending on if the PID has changed or not).
>
> I just want to avoid that, in case a user invokes "reload" twice too fast,
> Unicorn receives USR2 before preparing it so it dies. With my "hack" is more
> difficult such possibility to occur.
I'll look into what the consequences of writing the pid file after
signal handlers are setup later this week.
Unfortunately pid files are inherently racy for the USR2 case. Perhaps
your script can check the ctime of the pid file...
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 0%]
* Re: Issue when sending USR2 too soon
@ 2010-01-18 11:25 5% ` Iñaki Baz Castillo
2010-01-18 11:43 0% ` Eric Wong
0 siblings, 1 reply; 27+ results
From: Iñaki Baz Castillo @ 2010-01-18 11:25 UTC (permalink / raw)
To: mongrel-unicorn
El Lunes, 18 de Enero de 2010, Eric Wong escribió:
> Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > El Domingo, 17 de Enero de 2010, Iñaki Baz Castillo escribió:
> > > What about if Unicorn very quicky prepares the trap for USR2 so in case
> > > it receives it soon when starting it ignores it (and logs some
> > > warning)? Does it make sense?
> >
> > Adding the following on the top of bin/unicorn solves the problem:
> >
> > # Ignore USR2 (instead of terminating script) in case it arrives too
> > soon. trap("USR2") do
> > $stderr.puts "WARN: USR2 signal (reload action) received too soon,
> > ignored" end
>
> No it doesn't, it just reduces the window where signals aren't setup.
> On systems where Unicorn is installed as a RubyGem, that window of time
> may be much bigger.
But note that I've added:
trap("USR2") do
$stderr.puts "WARN: USR2 signal (reload action) received too soon,
ignored"
end
at the beginning of the executable, so the time window is really reduced. Also
note that in my modified version of the executable I load many other gems and
them make the unicorn loading slower, increasing the time window.
> Is the issue with a script reading the pid file and sending the signal
> because it exists?
I've done a init script to start/stop/reload/log-rotate Unicorn. The action
"log-rotate" takes the PID from the pid file and sends a USR1 (this call is
made by logrotate). The action "reload" sends a USR2 and later a TERM
(depending on if the PID has changed or not).
I just want to avoid that, in case a user invokes "reload" twice too fast,
Unicorn receives USR2 before preparing it so it dies. With my "hack" is more
difficult such possibility to occur.
Thanks.
--
Iñaki Baz Castillo <ibc@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 5%]
Results 1-27 of 27 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2010-01-17 1:44 Issue when sending USR2 too soon Iñaki Baz Castillo
2010-01-17 1:59 ` Iñaki Baz Castillo
2010-01-18 11:04 ` Eric Wong
2010-01-18 11:25 5% ` Iñaki Baz Castillo
2010-01-18 11:43 0% ` Eric Wong
2010-01-18 11:48 0% ` Iñaki Baz Castillo
2011-03-22 19:19 unicorn 1.1.x never-ending listen loop IOError exceptions David Nghiem
2011-03-22 21:39 ` Eric Wong
2011-03-23 0:04 7% ` David Nghiem
2011-03-23 1:09 ` Eric Wong
[not found] ` <AANLkTim3xZMKxcmQzPjcB7vrJKiHoc2f8WoU8RatrDum@mail.gmail.com>
2011-03-29 16:24 8% ` Eric Wong
2011-03-29 16:54 29% ` [PATCH] add examples/logrotate.conf Eric Wong
2011-03-31 17:45 Reopening logs - why no relative paths? Matthew Kocher
2011-03-31 22:02 ` Eric Wong
2011-04-01 23:15 5% ` Eric Wong
2011-04-12 16:13 10% Struggling with logrotate and unicorn Emmanuel Gomez
2011-04-12 17:58 6% ` Eric Wong
2011-04-12 18:36 5% ` Emmanuel Gomez
2011-04-12 18:59 5% ` Eric Wong
2011-04-12 22:38 5% ` Emmanuel Gomez
2011-04-12 22:51 5% ` Eric Wong
2011-04-12 23:01 6% ` Emmanuel Gomez
2015-03-12 1:04 On USR2, new master runs with same PID Kevin Yank
2015-03-12 1:45 ` Eric Wong
2015-03-12 6:26 ` Kevin Yank
2015-03-12 6:45 ` Eric Wong
2015-03-20 1:55 5% ` Kevin Yank
2015-03-20 1:58 ` Kevin Yank
2015-03-20 2:08 5% ` Eric Wong
2015-07-15 22:05 1% [PATCH] doc: remove references to old servers Eric Wong
2015-07-24 13:54 Question: How to limit size of log & error files Dowd, Stephen
2015-07-24 14:05 5% ` Ben Lovell
2015-07-24 17:13 8% ` Eric Wong
[not found] <56AAAD0A.8000807@icloud.com>
2016-01-30 9:34 5% ` unicorn log attack? Eric Wong
2016-03-31 1:41 5% [PATCH] doc: further trimming to reduce noise Eric Wong
2016-06-20 20:00 35% [PATCH] examples/logrotate.conf: update example for systemd Eric Wong
[not found] <20161031-unicorn-5.2.0-released@bogomips.org>
2016-10-31 20:04 4% ` [ANN] unicorn 5.2.0 - Rack HTTP server for fast clients and *nix Eric Wong
2017-09-14 8:25 Bug, probably related to Unicoen Felix Yasnopolski
2017-09-14 9:15 4% ` Eric Wong
2018-11-07 23:38 18% [PATCH] doc: update more URLs to use HTTPS and avoid redirects Eric Wong
2020-01-14 7:46 10% [PATCH] doc: s/bogomips.org/yhbt.net/g Eric Wong
2020-01-14 7:46 10% ` 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).