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: Clifton King Newsgroups: gmane.comp.lang.ruby.unicorn.general Subject: Re: synchronous restart Date: Tue, 31 Aug 2010 15:15:04 -0500 Message-ID: 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" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1283285717 21087 80.91.229.12 (31 Aug 2010 20:15:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 31 Aug 2010 20:15:17 +0000 (UTC) To: unicorn list Original-X-From: mongrel-unicorn-bounces@rubyforge.org Tue Aug 31 22:15:15 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:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=unuxQppc/p/R1SJj1wptBpCQHsqBwWrwi1OyJJPTDC0=; b=Pkp1XBaDMi7+Lo8TdKIDIGtYkT5EvyN9NH06oP/WNACwv5EJKrFtN9nAGHZrAho4FN o+iH3FZTm/KGpDzOfdTmIp5BZUu/f5PgGw5aPfbE6I4TrxkqpYlY8Kpr91iwC7uZUZGC t3VoouHGo1Vnww9I8ea6jDM3S1FJ7er5Aq26A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=L+SkPlDz+SjCRl+SE+n/CwMpNTsnsfqHV5r4HkEM36cxkE0O1uAkvkJsoFAyIgAy9t ENoG1a//s5xia2S2mIk0hiq3U+zskTguVdYJBy0alTHV7m2ZrgjCyBhFqlZ/3BdUYfCR kx/9RefFYb6AGZ7BYHRWZu44DzXrozT+mKpdc= 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:696 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OqXEc-0007pB-Is for gclrug-mongrel-unicorn@m.gmane.org; Tue, 31 Aug 2010 22:15:10 +0200 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id EF4801858372; Tue, 31 Aug 2010 16:15:09 -0400 (EDT) Received: from mail-fx0-f50.google.com (mail-fx0-f50.google.com [209.85.161.50]) by rubyforge.org (Postfix) with ESMTP id 486381858346 for ; Tue, 31 Aug 2010 16:15:06 -0400 (EDT) Received: by fxm20 with SMTP id 20so4783592fxm.23 for ; Tue, 31 Aug 2010 13:15:05 -0700 (PDT) Received: by 10.239.183.147 with SMTP id u19mr442681hbg.109.1283285704358; Tue, 31 Aug 2010 13:15:04 -0700 (PDT) Received: by 10.239.148.132 with HTTP; Tue, 31 Aug 2010 13:15:04 -0700 (PDT) Jamie, Check to see that the new unicorn master process has a different PID than the old one. You could have a script that sleeps for X seconds and checks the PID after the deploy and if it matches the old one alerts you with a tail of the stdout/stderr log files. I personally do "ps aux | grep unicorn" a few times during the process if there are any changes being deployed I'm wary of. Clifton On Tue, Aug 31, 2010 at 3:08 PM, Jamie Wilkinson wrote: > On Aug 31, 2010, at 12:08 PM, Clifton King wrote: > >> If the new master process >> fails at booting, you can tail the unicorn.stdout/err.log files to see >> why. > > > 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? > > It is extremely infrequent that our unicorns fail to start, but when it does we sometimes don't notice for quite some time. Our unicorns also restart so quickly that it is not an issue to do the restarts synchronously during deployment and trade speed for peace of mind > > I will probably just replace our basic `kill -USR2` with a small script that sends the signal and doesn't exit until the pidfile handover is complete. I'll be sure to share my results in case anyone else might find this useful. > > > -jamie > > http://jamiedubs.com | http://fffff.at > >> On Tue, Aug 31, 2010 at 1:30 PM, Jamie Wilkinson wrote: >>> Has anyone tried to synchronously restart their unicorns, to ensure that things restart OK? >>> >>> I imagine I could write a script that sent USR2 and then watched the log for a successful before exiting, but I dream there is something more MAGICAL >>> >>> >>> Yours in mythical web servers, >>> >>> -jamie >>> >>> _______________________________________________ >>> 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 >>> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 > _______________________________________________ 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