From: Eric Wong <normalperson@yhbt.net>
To: unicorn list <mongrel-unicorn@rubyforge.org>
Subject: Re: "unicorn -D" always returns 0 "success" (even when failed to load)
Date: Wed, 23 Dec 2009 07:26:17 +0000 [thread overview]
Message-ID: <20091223072617.GA28704@dcvr.yhbt.net> (raw)
In-Reply-To: <200912230320.59469.ibc@aliax.net>
Iñaki Baz Castillo <ibc@aliax.net> wrote:
> Hi, I'm writing a Debian init script for unicorn and realized that when
> starting unicorn with daemonize option, the command always returns 0, even if
> the start action failed (due for example Errno::EADDRINUSE).
>
> Returning 0 in such case is not good as it breaks service init scripts or
> service controllers (as HeartBeat) that fully rely on the appropriate exit
> code.
>
> Is there some way to determine if unicorn failed to start when using "-D"?
Hi Iñaki,
No way to determine that currently, as I've never encountered the need.
For validating startups, most folks I know have specific endpoint(s) in
application dedicated to checks. That way they can get way more info
and all the way down into stack including things like database/memcached
connections.
Anything less is superficial because they can fail to detect other
misconfigurations (including stuff like wrong RAILS_ENV); not just
startup errors.
> Another related issue: When the Rack config.ru file contains some error (as a
> typo) the worker(s) returns 1 (at the moment usually). Then unicorn master
> process reapes the terminated worker process and restarts it. Of course it
> would fail again and again. Anyhow "unicorn -D" returns 0 again (success).
>
> Usually if a worker (all the workers) fail to start at the moment of running
> it, it obviously means that there is some error in the application with
> prevents it to run. It could be great if Unicorn could detect it.
I'm generally hesitant to introduce code/features/bloat that aren't
helpful to people who properly test configurations before deploying :)
Adding this code doesn't solve problems. Either way the site can become
inaccessible/unusable and problems are noticeable very quickly.
If there's sufficient interest, I'll consider accepting a small patch
for this. Right now I'm unconvinced...
> For that I suggest something as a new option "--validation-time TIME". Let's
> suppose TIME is 5 seconds. In case *all* the workers fail within 5 seconds
> after starting unicorn, then unicorn understands that the Rack application is
> wrong (or any other error as Errno::EADDRINUSE) so terminates all the workers
> and itself (and hopefully returns 1 or any other non-zero exit status).
>
> Of course, all the above means that Unicorn should wait TIME seconds before
> being daemonized (so after TIME seconds it can decide which code to return).
>
> Does it make sense? Thanks a lot.
We avoid introducing command-line options since they're unlikely to be
compatible with "rackup" parsing of the "#\" lines in .ru files.
--
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
next prev parent reply other threads:[~2009-12-23 7:26 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-23 2:20 "unicorn -D" always returns 0 "success" (even when failed to load) Iñaki Baz Castillo
2009-12-23 7:26 ` Eric Wong [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2009-12-26 4:29 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
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
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=20091223072617.GA28704@dcvr.yhbt.net \
--to=normalperson@yhbt.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).