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 16:47:51 +0100 Message-ID: <200912261647.51764.ibc@aliax.net> References: <200912260529.45530.ibc@aliax.net> <20091226061652.GB22433@dcvr.yhbt.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 1261842490 9177 80.91.229.12 (26 Dec 2009 15:48:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Dec 2009 15:48:10 +0000 (UTC) To: mongrel-unicorn@rubyforge.org Original-X-From: mongrel-unicorn-bounces@rubyforge.org Sat Dec 26 16:48:03 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: <20091226061652.GB22433@dcvr.yhbt.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:253 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.50) id 1NOYs6-0008AY-RD for gclrug-mongrel-unicorn@m.gmane.org; Sat, 26 Dec 2009 16:48:03 +0100 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 664E916782B8; Sat, 26 Dec 2009 10:47:59 -0500 (EST) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by rubyforge.org (Postfix) with ESMTP id 1AAD5185826F for ; Sat, 26 Dec 2009 10:47:57 -0500 (EST) Received: by fxm26 with SMTP id 26so9287203fxm.19 for ; Sat, 26 Dec 2009 07:47:57 -0800 (PST) Received: by 10.223.164.104 with SMTP id d40mr9276715fay.98.1261842475857; Sat, 26 Dec 2009 07:47:55 -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 15sm3470815fxm.14.2009.12.26.07.47.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 26 Dec 2009 07:47:53 -0800 (PST) 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 t= he = 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 proce= ss = it will always receive 'true' (a zombie process is a process which can rece= ive = signals, it's does exist). If I could check if the master process is zombie then I wouldn't need = Process.detach, but I don't know how to check if a process is zombie, no wa= y = in: http://ruby-doc.org/core/classes/Process.html http://ruby-doc.org/core/classes/Process/Status.html Any suggestion here? = > 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). Sure, I'll change it. = > I would trap() in the parent before any forking, in case the > sleep time is ever so low there's a race condition. Ok. > Probably no need to handle USR1, either, just let the parent die on its o= wn, Note that the parent sleeps for 'min_running_time' + 1 (to avoid exiting = before receiving USR1 or USR2 from the controller process). But if the = controller process sends USR1 then the parent can already exit without wait= ing = one second more. Well, this is not very interesting, but I think it's good in order to get a = faster exit code (it's not a good idea that a daemon takes long time to sta= rt = and return ans exit status). > or alternatively, have the parent sleep forever in case something > unforseen happens in the children... But then the parent process doesn't end and continues in foreground. This i= s = not valid for running as daemon. The parent process must exit with the = appropriate status code after a few seconds to behave as any service runnin= g = in background. > > The code works for me for the two cases I explained in my previous mail. > > Of course it's an optional feature (I've implemented it with "-M --min- > > running-time SECONDS" in the options parser). > = > I believe the nginx grace period is hard-coded at 5 seconds, which should > be enough. Sorry, I don't know ngix. I need to use other reverse proxy (Pound) but let= me = open a new thread about it :) Anyhow I don't understand what you mean with "nginx grace period". How does = affect to Unicorn? Do you mean that, in case of implementing the above, = Unicorn wouldn't need a --min-running-time option? (I expect it would be = required since Unicorn is 100% independent of ngix) Really thanks a lot. I'll do the changes you suggest and show you again (bu= t = still don't know how to avoid Process.detach for now...). -- = 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