Re: Monit+Heartbeat using upstart in Ubuntu (feisty)

[Alex Stewart]

After some more experimenting with upstart using other (simple
(non-forking), non monit) processes that *are* respawned and some
research, it appears this is actually due to a specific limitation of
the current version of Upstart - namely that it cannot respawn any
process that forks (it currently doesn't use/have support for PID
files - see: http://www.mail-archive.com/address@hidden/msg00141.html)

Does anyone have a work-around for this?

-Alex

On 8/29/07, Alex Stewart <address@hidden> wrote:
> Dear All,
>
> Whilst this is really an upstart question, as upstart's documentation
> has for the most part still to attain a true corporeal form given the
> relative youth of the project and my question is something that anyone
> using monit+heartbeat in Feisty is likely to have encountered I am
> posting here in the hope that someone knows the answer.
>
> Basically although monit is started up correctly (the first time) when
> the monit-eventd file (included below) is in the /etc/event.d
> directory on boot, if the monit process is then manually killed it is
> *not* respawned.
>
> Based on the experiences of others and bug posts, I have experimented
> with placing the 'respawn' literal above and below the 'exec' line
> (upstart version: 0.3.8-1), which does alter the behaviour in that
> with respawn *above* the exec line, one instance of monit is spawned
> for each of the run levels for which there exists a start command.
> Whilst with respawn below, only one instance of monit is started.
>
> Any suggestions will be gratefully received!
>
> Alex
>
>
> # monit (local) event.d file (place in /etc/event.d)
>
> start on runlevel 2
> start on runlevel 3
> start on runlevel 4
> start on runlevel 5
>
> stop on runlevel 0
> stop on runlevel 1
> stop on runlevel 6
>
> console output
>
> exec /usr/sbin/monit -c /usr/local/bfrt-monit/monitrc
> respawn
>