unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: "Iñaki Baz Castillo" <ibc@aliax.net>
To: mongrel-unicorn@rubyforge.org
Subject: Re: "unicorn -D" always returns 0 "success" (even when failed to load)
Date: Sat, 26 Dec 2009 19:23:24 +0100	[thread overview]
Message-ID: <200912261923.24626.ibc@aliax.net> (raw)
In-Reply-To: <200912261647.51764.ibc@aliax.net>

El Sábado, 26 de Diciembre de 2009, Iñaki Baz Castillo escribió:
> El Sábado, 26 de Diciembre de 2009, Eric Wong escribió:
> > >   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 which
>  can receive signals, it's does exist).


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.
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ñaki Baz Castillo <ibc@aliax.net>
_______________________________________________
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


  reply	other threads:[~2009-12-26 18:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-26  4:29 "unicorn -D" always returns 0 "success" (even when failed to load) Iñaki Baz Castillo
2009-12-26  6:16 ` Eric Wong
2009-12-26 15:47   ` Iñaki Baz Castillo
2009-12-26 18:23     ` Iñaki Baz Castillo [this message]
2009-12-27  1:31       ` Eric Wong
2009-12-27  3:06         ` Iñaki Baz Castillo
2009-12-27  3:07           ` Iñaki Baz Castillo
2009-12-28  3:29           ` Eric Wong
2009-12-28 10:39             ` Iñaki Baz Castillo
2009-12-28 12:50             ` Iñaki Baz Castillo
2009-12-28 19:25               ` Eric Wong
2009-12-28 20:17                 ` Iñaki Baz Castillo
2009-12-28 20:32                   ` Eric Wong
2009-12-28 20:41                     ` Iñaki Baz Castillo
2009-12-29  0:17                       ` Eric Wong
2009-12-29  0:32                         ` Iñaki Baz Castillo
  -- strict thread matches above, loose matches on Subject: below --
2009-12-23  2:20 Iñaki Baz Castillo
2009-12-23  7:26 ` Eric Wong
2009-12-23 10:22   ` Iñaki Baz Castillo
2009-12-23 20:35     ` Eric Wong
2009-12-24  9:30       ` Iñaki Baz Castillo
2009-12-24 19:34         ` Eric Wong
2009-12-25 22:09           ` Iñaki Baz Castillo
2009-12-26  1:30             ` Iñaki Baz Castillo
2009-12-25 23:58   ` Iñaki Baz Castillo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://yhbt.net/unicorn/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200912261923.24626.ibc@aliax.net \
    --to=ibc@aliax.net \
    --cc=mongrel-unicorn@rubyforge.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhbt.net/unicorn.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).