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 749A121656 for ; Mon, 27 Jan 2014 17:02:34 +0000 (UTC) Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 4225C263071; Mon, 27 Jan 2014 17:02:34 +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 E569B263071 for ; Mon, 27 Jan 2014 17:02:24 +0000 (UTC) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 2DD7121655; Mon, 27 Jan 2014 17:02:23 +0000 (UTC) Date: Mon, 27 Jan 2014 17:02:23 +0000 From: Eric Wong To: mongrel-unicorn@rubyforge.org Subject: Re: listen loop error in 4.8.0 Message-ID: <20140127170223.GB7074@dcvr.yhbt.net> References: <20140127165640.GA7074@dcvr.yhbt.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140127165640.GA7074@dcvr.yhbt.net> User-Agent: Mutt/1.5.21 (2010-09-15) 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 Eric Wong wrote: > It seems io.close in the trap(:QUIT) handler of the worker process is > causing an IOError, which means an IO in the readers array already got > closed somehow. This shouldn't happen, and CRuby 2.x doesn't seem > to interrupt itself inside signal handlers[1]. Of course, the fake-signal mechanism of 4.8.0 could also cause this: * the master triggers a fake-signal (where the invoked trap handler is interruptible) * a real signal also triggered from an outside user I forget to mention this happened with unicorn-worker-killer 0.4.2 for that user, and that seems to just use normal Process.kill _______________________________________________ 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