Curtis j Schofield <[email protected]> wrote: > On Mon, Apr 25, 2011 at 11:34 AM, Eric Wong <[email protected]> wrote:
<snip> > > while test -f $UNICORN_PID_FILE > > do > > sleep 1 > > done > > If i run a wrapper with unicorn as a child process - i can detect the > absence of the wrapper - and > i can detect the absence of the pid file - but i cannot detect a hard > fail in the unicorn process unless i have some kind of pipe > open to the child and register that failure. > > Is my understanding correct? Yes, but the absence of the pid file usually means the unicorn process failed hard. Only unicorn error logs can tell you that definitively, though. I would probably make the wrapper script "exit 1" after the while loop in my script... > Daemontools is design to take a process that is running in the > foreground and monitor it - keep it alive - the breakdown in unicorn > is when a USR2 arrives at unicorn - and the pid switch occurs - daemon > tools believes it has lost the process. > > I see this as a design flaw in all pid based monitoring solutions - in > my experiences. Yes, it's a problem with the monitoring solution trying to do the job of the unicorn master process. Unicorn is designed to use the master process and there's no other way to do what Unicorn does without it. The unicorn master process itself should be very robust and never fail during normal operation (upgrades may break it if things go really wrong, but you already pay attention to what you're upgrading, right?). -- Eric Wong _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
