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: "unicorn -D" always returns 0 "success" (even when failed to load) Date: Wed, 23 Dec 2009 07:26:17 +0000 Message-ID: <20091223072617.GA28704@dcvr.yhbt.net> References: <200912230320.59469.ibc@aliax.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1261553189 19119 80.91.229.12 (23 Dec 2009 07:26:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Dec 2009 07:26:29 +0000 (UTC) To: unicorn list Original-X-From: mongrel-unicorn-bounces@rubyforge.org Wed Dec 23 08:26:22 2009 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: <200912230320.59469.ibc@aliax.net> 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:229 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.50) id 1NNLby-0005LX-Gc for gclrug-mongrel-unicorn@m.gmane.org; Wed, 23 Dec 2009 08:26:22 +0100 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 38038185830C; Wed, 23 Dec 2009 02:26:20 -0500 (EST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by rubyforge.org (Postfix) with ESMTP id 53BA1185830B for ; Wed, 23 Dec 2009 02:26:18 -0500 (EST) Received: from localhost (unknown [127.0.2.5]) by dcvr.yhbt.net (Postfix) with ESMTP id A82081F4EF; Wed, 23 Dec 2009 07:26:17 +0000 (UTC) I=F1aki Baz Castillo wrote: > Hi, I'm writing a Debian init script for unicorn and realized that when = > starting unicorn with daemonize option, the command always returns 0, eve= n if = > the start action failed (due for example Errno::EADDRINUSE). > = > Returning 0 in such case is not good as it breaks service init scripts or = > service controllers (as HeartBeat) that fully rely on the appropriate exi= t = > code. > = > Is there some way to determine if unicorn failed to start when using "-D"? Hi I=F1aki, No way to determine that currently, as I've never encountered the need. For validating startups, most folks I know have specific endpoint(s) in application dedicated to checks. That way they can get way more info and all the way down into stack including things like database/memcached connections. Anything less is superficial because they can fail to detect other misconfigurations (including stuff like wrong RAILS_ENV); not just startup errors. > Another related issue: When the Rack config.ru file contains some error (= as a = > typo) the worker(s) returns 1 (at the moment usually). Then unicorn maste= r = > process reapes the terminated worker process and restarts it. Of course i= t = > would fail again and again. Anyhow "unicorn -D" returns 0 again (success). > = > Usually if a worker (all the workers) fail to start at the moment of runn= ing = > it, it obviously means that there is some error in the application with = > prevents it to run. It could be great if Unicorn could detect it. I'm generally hesitant to introduce code/features/bloat that aren't helpful to people who properly test configurations before deploying :) Adding this code doesn't solve problems. Either way the site can become inaccessible/unusable and problems are noticeable very quickly. If there's sufficient interest, I'll consider accepting a small patch for this. Right now I'm unconvinced... > For that I suggest something as a new option "--validation-time TIME". Le= t's = > suppose TIME is 5 seconds. In case *all* the workers fail within 5 second= s = > after starting unicorn, then unicorn understands that the Rack applicatio= n is = > wrong (or any other error as Errno::EADDRINUSE) so terminates all the wor= kers = > and itself (and hopefully returns 1 or any other non-zero exit status). > = > Of course, all the above means that Unicorn should wait TIME seconds befo= re = > being daemonized (so after TIME seconds it can decide which code to retur= n). > = > Does it make sense? Thanks a lot. We avoid introducing command-line options since they're unlikely to be compatible with "rackup" parsing of the "#\" lines in .ru files. -- = 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