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.7 required=5.0 tests=MSGID_FROM_MTA_HEADER, RP_MATCHES_RCVD shortcircuit=no autolearn=unavailable version=3.3.2 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?q?I=F1aki_Baz_Castillo?= Newsgroups: gmane.comp.lang.ruby.unicorn.general Subject: Re: "unicorn -D" always returns 0 "success" (even when failed to load) Date: Sat, 26 Dec 2009 19:23:24 +0100 Message-ID: <200912261923.24626.ibc@aliax.net> References: <200912260529.45530.ibc@aliax.net> <20091226061652.GB22433@dcvr.yhbt.net> <200912261647.51764.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 1261851829 31458 80.91.229.12 (26 Dec 2009 18:23:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Dec 2009 18:23:49 +0000 (UTC) To: mongrel-unicorn@rubyforge.org Original-X-From: mongrel-unicorn-bounces@rubyforge.org Sat Dec 26 19:23:41 2009 Return-path: Envelope-to: gclrug-mongrel-unicorn@m.gmane.org X-Original-To: mongrel-unicorn@rubyforge.org Delivered-To: mongrel-unicorn@rubyforge.org User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; ) In-Reply-To: <200912261647.51764.ibc@aliax.net> 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:254 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.50) id 1NObIh-0005Ui-Kr for gclrug-mongrel-unicorn@m.gmane.org; Sat, 26 Dec 2009 19:23:39 +0100 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 88D00185828D; Sat, 26 Dec 2009 13:23:39 -0500 (EST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by rubyforge.org (Postfix) with ESMTP id 44A8E185826F for ; Sat, 26 Dec 2009 13:23:37 -0500 (EST) Received: by fg-out-1718.google.com with SMTP id e21so1083698fga.5 for ; Sat, 26 Dec 2009 10:23:30 -0800 (PST) Received: by 10.86.22.6 with SMTP id 6mr1741891fgv.69.1261851809378; Sat, 26 Dec 2009 10:23:29 -0800 (PST) Received: from ibc-laptop.localnet (16.85-84-188.dynamic.clientes.euskaltel.es [85.84.188.16]) by mx.google.com with ESMTPS id 16sm3498498fxm.0.2009.12.26.10.23.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 26 Dec 2009 10:23:27 -0800 (PST) El S=E1bado, 26 de Diciembre de 2009, I=F1aki Baz Castillo escribi=F3: > El S=E1bado, 26 de Diciembre de 2009, Eric Wong escribi=F3: > > > http://oversip.net/public/min_time_running.rb > > > > > > It contains a modification for bin/unicorn and a rewritten > > > lib/unicorn/launcher.rb. > > > > Interesting, I could be tempted to accept this with a few changes... > > > > Process.detach() spawns a background Thread. Having running threads > > before forking won't fly with certain OS threading libraries (some > > versions of FreeBSD, I believe, check MRI Redmine for some open bugs). > = > Yes, but there is a problem: > Imagine I don't use Process.detach and the master process ends when loads > the rack application (due to a typo or due to an error in unicorn conf > file). Then the master process would remain visible/alive but as zombie. > If so, when the controller process sends signal 0 to check the master > process it will always receive 'true' (a zombie process is a process whi= ch > can receive signals, it's does exist). Hi, I've improved it a bit with your suggestions and also simplified it a l= ot. Now there is no a "controller process". Instead, if "Unicorn.run" raises th= en = master process rescues the exception and sends USR1 to parent process so it = exists with 1. So, Process.detach is not used anymore :) Please check it from here: http://oversip.net/public/unicorn_addons.rb > > Use trap(Symbol), trap(Integer) is harder to read and has a likelyhood > > of being non-portable for certain signals. Likewise with Process.kill > > (0 being the only exception, of course). Done in new code. = > > I would trap() in the parent before any forking, in case the > > sleep time is ever so low there's a race condition. Done in new code. = > > Probably no need to handle USR1, either, just let the parent die on its > > own, Now just one signal plays: USR1. It is sent by master process to parent = process if Unicorn.run raised an exception. Regards. -- = I=F1aki Baz Castillo _______________________________________________ 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