I totally get what Jamie is asking for, I'm in the same boat.
I think Jamie was saying he wants to avoid tailing the log while
deploying new code. The only thing you want to know is 0 for success or
-1 for failure, only in the case of -1 would you make the effort to have
your brain waste time parsing log data.
Jamie, I was thinking of modifying my unicorn init.d script somewhat
similar to this from a suggested nginx init.d script:
http://wiki.nginx.org/Nginx-init-ubuntu
see the quietupgrade() function.
As Unicorn follows the nginx patterns it'll be mostly a copy-paste I think.
Cheers,
Lawrence
On Tue, Aug 31, 2010 at 4:08 PM, Jamie Wilkinson <[email protected]> wrote:
I should clarify... the above is exactly what I'm trying to avoid. i.e. how do
you know if your new master failed to boot unless you are actively tailing the
logs?
Well, first, you can specify a .pid file in your Unicorn configuration
file, then look at it before and a few seconds after the USR2 signal
to see if the process IDs are different. Unicorn's pretty smart about
maintaining that file, and copying the old one out until you kill the
old process.
Second... I'm confused as to why you think tailing the logs is
something to be avoided. Isn't finding out status what logs are
*for?* You could certainly automate the inspection and have some
process that emails you with an alarm if things don't look right.
Regardless of how you do it, if you're hoping to get away with
frequent automated deploys without *some* verification that requests
are working, you're taking big risks. Even if your unicorn process
runs, you could still have problems at the application level throwing
exceptions at every user.
_______________________________________________
Unicorn mailing list - [email protected]
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
