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/[EMAIL PROTECTED]/msg00141.html)
Does anyone have a work-around for this? -Alex On 8/29/07, Alex Stewart <[EMAIL PROTECTED]> 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 > -- To unsubscribe: http://lists.nongnu.org/mailman/listinfo/monit-general
