mythtv at hotblack
Jul 2, 2007, 4:17 PM
Post #23 of 36
(10877 views)
Permalink
|
>So, maybe I have a misconcenception about how the PID is supposed to
>relate to the application that created it.
>
>Running mythbackend with the following "mythbackend --pidfile
>/var/run/mythtv/" creates a PID file however when I stop mythbackend
>at the CL the PID file is not deleted, are you saying that monit will
>be able to tell that mythbackend has stopped and it will try to
>re-launch it?
>
>I was not able to get monit to work when I tried it before, could it
>be because I'm running svn?
>
>Are you running SVN as well? would you mind posting your portion
>related to mythbackend in its entirety?
>
>AJM,
I haven't read al the docs for monit, and my only real linux
experience has been the last 2 years playing my myth setup, so what
follows is my understanding of how this all works. With that said:
I'm not running SVN, but I was running atrpms/FC5 following Jarod's
guide, and just recently switched to MythDora 4 (FC6) and have been
using monit on both of those.
On my machine mythbackend is started or stopped using
/sbin/service mythbackend start|stop
and the init.d script takes care of removing the pid file (not
mythbackend itself).
I don't think SVN should make any difference, you could set monit to
not care about the pid (but yours sounds like it's working the way it
should).
The excerpt from my /etc/monitrc was everything related to myth. It
tells monit to check the mythbackend process that should have a pid
file, and should respond via TCP on port 6544. Monit checks to see
if there is a process called mythbackend running. If there isn't it
starts it, and emails me. If there is one running, it checks the
current pid against the one in the pid file. If it's different, it
tries to start mythbackend, and emails me. If there is one running
it checks the TCP port, and if that fails, it tries to restart it and
emails me.
So no matter what if there isn't a mythbackend running successfully,
monit jumps in and tries to get it going.
If you want to stop mythbackend for some reason, then use
monit stop mythbackend
and that in turn stops the backend and removes the pid, and then
monit stops monitoring it.
So the config files I have are
/etc/monit/monit_delay
-----------------
#! /bin/sh
# this lets the machine startup and get settled
# before monit starts worrying that mythbackend isn't going
sleep 10
/usr/local/bin/monit monitor mythbackend
-----------------
/etc/monit (excerpt of the stuff I added/changed)
-----------------
set daemon 60
set logfile /var/log/monit.log
set mailserver my.mail.server
set alert me[at]my.mail.server
check process mythbackend with pidfile /var/run/mythbackend.pid
group mythtv
start program = "/sbin/service mythbackend start"
stop program = "/sbin/service mythbackend stop"
if failed port 6544 proto http then restart
mode manual
depends on mysql
check process mysql with pidfile /var/run/mysqld/mysqld.pid
group mythtv
start program = "/etc/init.d/mysqld start"
stop program = "/etc/init.d/mysqld stop"
if failed port 3306 then restart
mode manual
-----------------
So with all of this, if my backend dies, it should get kicked back
into life, and if it can't do that I should at the very least get
email notification of a problem. I should look into things further,
maybe add monitoring of /var/log/ to check for runaway logs, etc.
- Wade
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
|
1
