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ó:
> > > 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? :)
> 
> I had a lot of trouble coming to terms with this one myself :)
> 
> Eventually I reasoned that the heartbeat mechanism is to protect against
> unforeseen failures way down the line (and sometimes outside of the
> application's control).
> 
> It's (hopefully) common and expected to check applications shortly
> following deployments, so heartbeat isn't for that.

Yes, you are right.

 
> However applications have a tendency to break in unforseen ways, and
> only in production, and at the worst times.  These failures happen well
> after the app is deployed :)

Yes, every application breaks just in the moment that it shouldn't :)

However I'm building my app now and when start it it usually has errors, and 
that's good as it means I'm working :)
But sincerelly I would like to see the error just once rather than many times 
due to workers respawn :)

Also, is there any "interval" parameter so a worker is not re-spawned until 
such timeout (after die).




> > 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.
> 
> Under modern Linux systems, you have several options...
> 
>   tr '\0' ' ' < /proc/$PID/cmdline # show the command-line
> 
>   pmap $PID | grep unicorn_http.so # not many other things load this
> 
>   lsof -p $PID  # can check listening ports/log files

Yes! this is much better! :)

 
> Unfortunately I don't use other OSes enough to remember the
> equivalents...

The server will run just on Linux (Unix) server :)


> > 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?
> 
> I don't see how being under a specific PID actually matters.  Why not
> just write a script that sends an HTTP request to check?
> 
> Workers will die soon after the first request, or (timeout/2) seconds if
> a master dies anyways.

Well, in fact I want to code some console utility to get information from the 
application (loaded configuration, check the database(s) connection and so).
For that I was thinking in a DRb server running in the master because it must 
bind in some TCP port.

The problem is that I should stop the DRb server before master reexec to avoid 
EADDINUSE. Well, I could code some rescue block...




> > I didn't know about such options in .ru file. Are those options
> > supposed to be read by the backend?
> 
> I don't believe it's well-documented, I only found out from reading the
> rackup code and I'm not really a fan of magic comments, but they're only
> for the basic command-line arguments rackup handles:
> 
>   $ rackup -h
...
>  -D, --daemonize          run daemonized in the background

Why "daemonize" is not present in unicornf configuration file?


Really thanks a lot for all your help.



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