From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS33070 50.56.128.0/17 X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,RDNS_NONE shortcircuit=no autolearn=no version=3.3.2 X-Original-To: archivist@yhbt.net Delivered-To: archivist@dcvr.yhbt.net Received: from rubyforge.org (unknown [50.56.192.79]) by dcvr.yhbt.net (Postfix) with ESMTP id 6B0B544C218 for ; Tue, 26 Nov 2013 18:04:06 +0000 (UTC) Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id B9A28263071; Tue, 26 Nov 2013 18:04:06 +0000 (UTC) X-Original-To: mongrel-unicorn@rubyforge.org Delivered-To: mongrel-unicorn@rubyforge.org Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by rubyforge.org (Postfix) with ESMTP id 9359E263071 for ; Tue, 26 Nov 2013 18:04:02 +0000 (UTC) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 4C65844C210; Tue, 26 Nov 2013 18:04:00 +0000 (UTC) Date: Tue, 26 Nov 2013 18:04:00 +0000 From: Eric Wong To: unicorn list Subject: Re: What does it mean for the unicorn process to be bound to a terminal? Message-ID: <20131126180400.GA15932@dcvr.yhbt.net> References: <5294A289.1020300@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5294A289.1020300@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Rodrigo Rosenfeld Rosas 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mongrel-unicorn-bounces@rubyforge.org Errors-To: mongrel-unicorn-bounces@rubyforge.org Rodrigo Rosenfeld Rosas wrote: > For a long time I struggle to understand this part: > > http://unicorn.bogomips.org/SIGNALS.html > > "3. You can now send WINCH to the old master process so only the new > workers serve requests. If your unicorn process is bound to an > interactive terminal, you can skip this step." > > I asked a teammate and he didn't understand this part either, so > maybe it's confusing for other people too. > > Would you mind to clarify what you mean by that? It means actions on the terminal which started unicorn won't affect it. So if the user hits Ctrl-C from the terminal, unicorn will not receive SIGINT. Likewise for Ctrl-\ and SIGINT, and if a user resizes his terminal (common with xterm and friends), there's no SIGWINCH. setsid(2) is the syscall used to detach from a controlling terminal (among other things). Maybe there's documentation elsewhere to the setsid(2) which explains this part more, but neither the POSIX nor Linux manpage for that distributed by Debian (wheezy) really explain this. > Also, a section with suggestions on how to properly automate a > deployment with no downtime would be helpful. > > What I see is that most recipes, like the ones I've seen for > Capistrano for example, will simply send a QUIT after USR2 to the > old master without actually checking if the deploy was successful > and won't use the WINCH and HUP signals to deal with health > checking... Patches welcome. I haven't deployed an app entirely with Capistrano in years nor do I use any common/widely-known deployment system. I usually just end using something like the init script in examples/init.sh _______________________________________________ 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