Re: "unicorn -D" always returns 0 "success" (even when failed to load)

["Iñaki Baz Castillo" <ibc@aliax.net>]

El Miércoles, 23 de Diciembre de 2009, Eric Wong escribió:

> 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.

Yes, you are right and I agree now. I was thinking in Unicorn as a final 
application rather than a HTTP applications container. It's like Apache, no 
body expects Apache to return 1 and exit in case a PHP application has a typo 
:)



> > 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.

Sure, but how to explain that to Hearteat? :)

 
> If there's sufficient interest, I'll consider accepting a small patch
> for this.  Right now I'm unconvinced...

I've taken a look to the code and such a feature would definitively make it 
ugly (IMHO).

So I'm thinking in a different approach: a custom script to check the status 
of the application. Such script would communicate with the application (maybe 
using DRB). If the DRB connection fails (because the workers fail to start) 
then it means that something wrong occurs. And such script would also return 
the whole status (DB connections and so).
I would include such script as "status" option in a service init script. The 
"start" action would call "status" after N seconds and decide if the 
*application* is running or not (if not then kill unicorn and exit 1).

PS: Since Unicorn makes usage of signals, is there any way to determine (by 
using a signal) if the process running with some PID is an unicorn process?

This is: usually to verify the process status the PID file/value is inspected. 
If there is a process running under such PID then we "assume" that process is 
Unicorn. In case that PID is stolen by any other process (since PID file 
wasn't deleted) nobody realizes of it.

A way to determine it could be asking to Unicorn master process (using i.e. 
DRB) its PID and match it against the PID value stored in the pidfile. Of 
course it would require some kind of communication with unicorn master process 
to get its PID, is it possible now in some way?



 
> > 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.

I didn't know about such options in .ru file. Are those options supposed to be 
read by the backend?


Thanks a lot.

-- 
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