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.6 required=5.0 tests=FREEMAIL_FROM, MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,T_DKIM_INVALID shortcircuit=no autolearn=unavailable version=3.3.2 Path: news.gmane.org!not-for-mail From: Lawrence Pit Newsgroups: gmane.comp.lang.ruby.unicorn.general Subject: Re: synchronous restart Date: Wed, 01 Sep 2010 09:59:15 +1000 Message-ID: <4C7D9753.9030507@gmail.com> References: <9ADECA6F-ED48-467D-8826-2C94BF42B18A@tramchase.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1283299177 6512 80.91.229.12 (31 Aug 2010 23:59:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 31 Aug 2010 23:59:37 +0000 (UTC) To: unicorn list Original-X-From: mongrel-unicorn-bounces@rubyforge.org Wed Sep 01 01:59:36 2010 Return-path: Envelope-to: gclrug-mongrel-unicorn@m.gmane.org X-Original-To: mongrel-unicorn@rubyforge.org Delivered-To: mongrel-unicorn@rubyforge.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=naetYZFBiEH8qot++i+6O9HanO9O38yR+6wgTpNkhEs=; b=JMLxXNcpmYDJJh05DtfDa3XdKe1FClAJrtNP3s75wZH5XuOxbpBNDJv/tAvKDYjBMT QU0kP4fotloA7pHL0N6r1KsU3HPqO6nLYisEeQD2UFFA3M/RBVPvp0Fc3fAUkF0EfEai ZUDLSn0poSzo6bwT/mUKzwwGLKxuYYxA1nZzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=iIWyN7gPUY/zXHYpe3fc8y8g5/NDKj7AJElLz5vqJhC++InpNiCrvnw0TjFwUQNVT+ QZcN6UhX9izpi4k85biSSgx+eoAjL13l1j83zJKG0OIpyIAiXQtaWWCAaZU5A6W6ZQFI 6yrXBnzDyv4cSEDKqUSMW3eP6DQP+Lgh4skH0= User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) In-Reply-To: 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:699 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Oqajm-0004kM-3W for gclrug-mongrel-unicorn@m.gmane.org; Wed, 01 Sep 2010 01:59:34 +0200 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id CF3A61678317; Tue, 31 Aug 2010 19:59:32 -0400 (EDT) Received: from mail-gx0-f178.google.com (mail-gx0-f178.google.com [209.85.161.178]) by rubyforge.org (Postfix) with ESMTP id AF77A1858368 for ; Tue, 31 Aug 2010 19:59:22 -0400 (EDT) Received: by gxk10 with SMTP id 10so3284960gxk.23 for ; Tue, 31 Aug 2010 16:59:22 -0700 (PDT) Received: by 10.100.127.19 with SMTP id z19mr7403900anc.130.1283299162330; Tue, 31 Aug 2010 16:59:22 -0700 (PDT) Received: from copa.local (124-169-15-137.dyn.iinet.net.au [124.169.15.137]) by mx.google.com with ESMTPS id x33sm15478021ana.33.2010.08.31.16.59.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 31 Aug 2010 16:59:21 -0700 (PDT) I totally get what Jamie is asking for, I'm in the same boat. I think Jamie was saying he wants to avoid tailing the log while deploying new code. The only thing you want to know is 0 for success or -1 for failure, only in the case of -1 would you make the effort to have your brain waste time parsing log data. Jamie, I was thinking of modifying my unicorn init.d script somewhat similar to this from a suggested nginx init.d script: http://wiki.nginx.org/Nginx-init-ubuntu see the quietupgrade() function. As Unicorn follows the nginx patterns it'll be mostly a copy-paste I think. Cheers, Lawrence > On Tue, Aug 31, 2010 at 4:08 PM, Jamie Wilkinson wrote: > >> I should clarify... the above is exactly what I'm trying to avoid. i.e. how do you know if your new master failed to boot unless you are actively tailing the logs? >> > > Well, first, you can specify a .pid file in your Unicorn configuration > file, then look at it before and a few seconds after the USR2 signal > to see if the process IDs are different. Unicorn's pretty smart about > maintaining that file, and copying the old one out until you kill the > old process. > > Second... I'm confused as to why you think tailing the logs is > something to be avoided. Isn't finding out status what logs are > *for?* You could certainly automate the inspection and have some > process that emails you with an alarm if things don't look right. > Regardless of how you do it, if you're hoping to get away with > frequent automated deploys without *some* verification that requests > are working, you're taking big risks. Even if your unicorn process > runs, you could still have problems at the application level throwing > exceptions at every user. > > > > > _______________________________________________ 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