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.5 required=5.0 tests=AWL,MSGID_FROM_MTA_HEADER, RP_MATCHES_RCVD shortcircuit=no autolearn=unavailable version=3.3.2 Path: news.gmane.org!not-for-mail From: Eric Wong Newsgroups: gmane.comp.lang.ruby.unicorn.general Subject: Re: "unicorn -D" always returns 0 "success" (even when failed to load) Date: Sun, 27 Dec 2009 19:29:02 -0800 Message-ID: <20091228032902.GC4349@dcvr.yhbt.net> References: <200912260529.45530.ibc@aliax.net> <200912261923.24626.ibc@aliax.net> <20091227013115.GA28140@dcvr.yhbt.net> <200912270406.39535.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 1261970952 12043 80.91.229.12 (28 Dec 2009 03:29:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Dec 2009 03:29:12 +0000 (UTC) To: unicorn list Original-X-From: mongrel-unicorn-bounces@rubyforge.org Mon Dec 28 04:29:05 2009 Return-path: Envelope-to: gclrug-mongrel-unicorn@m.gmane.org X-Original-To: mongrel-unicorn@rubyforge.org Delivered-To: mongrel-unicorn@rubyforge.org Content-Disposition: inline In-Reply-To: <200912270406.39535.ibc@aliax.net> User-Agent: Mutt/1.5.18 (2008-05-17) 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:262 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.50) id 1NP6I3-0002NI-SN for gclrug-mongrel-unicorn@m.gmane.org; Mon, 28 Dec 2009 04:29:04 +0100 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 2AF0115B802F; Sun, 27 Dec 2009 22:29:04 -0500 (EST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by rubyforge.org (Postfix) with ESMTP id 2DDE5185826F for ; Sun, 27 Dec 2009 22:29:03 -0500 (EST) Received: from localhost (unknown [127.0.2.5]) by dcvr.yhbt.net (Postfix) with ESMTP id A01391F50D; Mon, 28 Dec 2009 03:29:02 +0000 (UTC) I=F1aki Baz Castillo wrote: > El Domingo, 27 de Diciembre de 2009, Eric Wong escribi=F3: > > > Hi, I've improved it a bit with your suggestions and also simplified > > > it a lot. Now there is no a "controller process". Instead, if > > > "Unicorn.run" raises then master process rescues the exception and > > > sends USR1 to parent process so it exists with 1. > > = > > Hi, I realized Unicorn.run inside the daemonize method doesn't work. > = > Strange, it works for me... "Doesn't work" as in it's not friendly to servers based on Unicorn (like Rainbows!). > > However, I've reimplemented much of your idea here so it does not > > involve sleeping at all, but rather shares a pipe with the grandparent > > (started by the user) and Unicorn master process. The added benefit of > > using a pipe is that there's no fuzzy sleeping involved at or grace > > periods to worry about, too. > > = > > Also pushed out to the "ready_pipe" branch of > > git://git.bogomips.org/unicorn.git > > = > > Let me know how it goes. > > = > > If everything looks good, I'll consider merging for 0.96.0. > = > It's really awesome! I've tested it and it works great, and avoids the = > sleeping stuff and a new commandlline option. Congratulations :) The current version is actually slightly buggy in that it leaks the pipe descriptor... > However there is still a not solved case. Let me please explain it with t= wo = > examples: > = > 1) In "after_fork" I set: > worker.user("non_existing_user","non_existing_group") > = > The master process would start properly and would notify "success" to = > grandparent. (so the init script returns 0). But the fact is that all the = > workers fail to start and are respawned again and again. For that particular case there'll be a Unicorn::Configurator#user directive. But really, there's absolutely no good reason to use user switching in a backend application server like Unicorn. I only added that feature to support derivative servers like Rainbows!, and even then it's debatable since using things like iptables or load balancers can be used to redirect port 80 to arbitrary ports anyways. > 2) I use "Clogger" in my Rack config.ru. But I set a log file in a path t= hat = > doesn't exist. Clogger raises due to this (it doesn't try to create the f= ull = > path). > Again the master process has notified "success" to grandparent (exis stat= us 0 = > then) but the workers are respawned again and again. There's really an infinite number of ways to screw things up badly in workers and cause them to flap. It's not possible to protect careless users from all of them, so attempting to do so would be a waste of effort. Avoiding user-switching in an app server is a great first step, as it eliminates an entire class of problems :) -- = Eric Wong _______________________________________________ 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