On Tue, Nov 26, 2013 at 12:42 PM, Michael Fischer <mfisc...@zendesk.com> wrote:
> I'd suggest that you monitor Unicorn by issuing a test request to it
> via its listening socket instead. Ultimately, you're more likely
> concerned about whether Unicorn is serving requests, not whether its
> pid file exists. (Such a check can also lead to false positives;
> consider what might happen if an admin or the Linux OOM killer sends
> it a SIGKILL, leaving the pid file intact.)
Great suggestion, thanks. I've added that, as shown below, in case
others are interested. Though perhaps not necessary, am still checking
the PID file as well so it will start asap on absence of the pid file.
@Eric: Thanks for that change.
check process unicorn
with pidfile /srv/app.example.com/shared/pids/unicorn.pid
group web
start program = "/etc/init.d/unicorn start"
stop program = "/etc/init.d/unicorn stop"
if mem > 300.0 MB for 1 cycles then restart
if cpu > 50% for 2 cycles then alert
if cpu > 80% for 3 cycles then restart
if failed unixsocket /tmp/.unicorn_sock type tcp protocol http
and request '/ping' hostheader 'app.example.com'
with timeout 20 seconds for 2 cycles
then restart
--
Jimmy
_______________________________________________
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
