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. -- Have Fun, Steve Eley ([email protected]) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
