"unicorn -D" always returns 0 "success" (even when failed to load)
Iñaki Baz Castillo
ibc at aliax.net
Thu Dec 24 04:30:01 EST 2009
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
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 at aliax.net>
More information about the mongrel-unicorn