From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS14383 205.234.109.0/24 X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,MSGID_FROM_MTA_HEADER, RP_MATCHES_RCVD shortcircuit=no autolearn=unavailable version=3.3.2 Path: news.gmane.org!not-for-mail From: Eric Wong Newsgroups: gmane.comp.lang.ruby.unicorn.general Subject: Re: [ANN] unicorn 0.990.0 - inching towards 1.0 Date: Thu, 10 Jun 2010 07:38:50 +0000 Message-ID: <20100610073850.GA28455@dcvr.yhbt.net> References: <20100608095140.GB30419@dcvr.yhbt.net> <20100609182245.GB8027@dcvr.yhbt.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1276156625 12123 80.91.229.12 (10 Jun 2010 07:57:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 10 Jun 2010 07:57:05 +0000 (UTC) To: unicorn list Original-X-From: mongrel-unicorn-bounces@rubyforge.org Thu Jun 10 09:57:04 2010 Return-path: Envelope-to: gclrug-mongrel-unicorn@m.gmane.org X-Original-To: mongrel-unicorn@rubyforge.org Delivered-To: mongrel-unicorn@rubyforge.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: mongrel-unicorn@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: mongrel-unicorn-bounces@rubyforge.org Errors-To: mongrel-unicorn-bounces@rubyforge.org Xref: news.gmane.org gmane.comp.lang.ruby.unicorn.general:561 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OMcdM-0005vC-Bd for gclrug-mongrel-unicorn@m.gmane.org; Thu, 10 Jun 2010 09:57:04 +0200 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 77F361858366; Thu, 10 Jun 2010 03:57:01 -0400 (EDT) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by rubyforge.org (Postfix) with ESMTP id 683CB185837F for ; Thu, 10 Jun 2010 03:38:51 -0400 (EDT) Received: from localhost (unknown [127.0.2.5]) by dcvr.yhbt.net (Postfix) with ESMTP id 973621F44B; Thu, 10 Jun 2010 07:38:50 +0000 (UTC) Alexander Simonov wrote: > On Jun 9, 2010, at 9:22 PM, Eric Wong wrote: > > Alexander Simonov 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 http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying