unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: Eric Wong <normalperson@yhbt.net>
To: unicorn list <mongrel-unicorn@rubyforge.org>
Subject: Re: [ANN] unicorn 0.990.0 - inching towards 1.0
Date: Thu, 10 Jun 2010 07:38:50 +0000	[thread overview]
Message-ID: <20100610073850.GA28455@dcvr.yhbt.net> (raw)
In-Reply-To: <EFCFB26E-2D97-4DB1-AD50-141D224D9B4A@simonov.me>

Alexander Simonov <alex@simonov.me> wrote:
> On Jun 9, 2010, at 9:22 PM, Eric Wong wrote:
> > Alexander Simonov <alex@simonov.me> wrote:
> >> 
> >> Hello!
> >> 
> >> One question: it's a normal state if i start rails app without preload
> >> and after Gem.refresh all works go down by exception from Ge.refresh
> >> and master process all time trying reup they.  And it's go to
> >> recursion. I know it's issue of people who start app, but in any case
> >> it's must be exception for stop of master process. Is i check code
> >> when starts workers and if we have preload_app false method run
> >> build_app!.  If we have preload_app true - then we check it before
> >> start worker. 
> > 
> > Hi Alexander,
> > 
> > I hope I'm understanding you correctly, so you want the master process
> > to die if you've misdeployed or misconfigured your app?
> yes, something like this.
> > 
> > This is one of those sharp edges of Unicorn that might be pointless
> > to protect against with preload_app=false...
> > 
> > The general rule is that you shouldn't be mucking around with Gem (or
> > any other library) installations on a production server unless you're
> > deploying.  And whenever you're deploying, you would always be checking
> > to see you've deployed correctly anyways, so you can detect any screwups
> > in the installation/deployment.
> > 
> > Let me know if that makes sense.
> Ok. But the main thing is the master process goes to recursion restart
> of workers if they return exit or exception.May be add the counter?
> For example, 10 times we trying to respawn working process and after
> stop master.  I think it makes sense. 

It'd have to be a time-aware counter, because sometimes slightly broken
_will_ exit/die 10 times over the period of an hour.  But the site can
still be making enough money with 99.8% successful service and not
care about spending time/resources fixing the last 0.2% :)

But even with a proper time-aware counter, the app is still broken at
deploy time.  So I don't believe there is much point in adding more code
just to exit the process when the proper solution is for the user to
_fix_ the app.

And again (I seem to remember saying this months ago), any time you're
deploying, you should be paying extra attention to the app anyways.
That means testing with actual HTTP requests, not just seeing of the
process is up.  Just having a running process serving error pages is
equally worthless as not running the server at all.

Eric Wong
Unicorn mailing list - mongrel-unicorn@rubyforge.org
Do not quote signatures (like this one) or top post when replying

  reply	other threads:[~2010-06-10  7:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-08  9:51 [ANN] unicorn 0.990.0 - inching towards 1.0 Eric Wong
2010-06-09  8:39 ` Alexander Simonov
2010-06-09 18:22   ` Eric Wong
2010-06-10  5:26     ` Alexander Simonov
2010-06-10  7:38       ` Eric Wong [this message]
2010-06-10  8:46         ` Alexander Simonov
2010-06-11  1:27           ` Eric Wong
2010-06-11 18:00             ` Alexander Simonov
2010-06-11 20:37 ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://yhbt.net/unicorn/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100610073850.GA28455@dcvr.yhbt.net \
    --to=normalperson@yhbt.net \
    --cc=mongrel-unicorn@rubyforge.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


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