Re: depend take 2

[Rory Toma]

There is still one more bug. With the following monitrc, there are 2
problems that I see so far.

1) running "monit stop sshd" only stops xinetd and sshd, gpm does not
get stopped.

2) If I kill sshd, the validation looks like:

[PST Dec 20 11:28:45] stop: (xinetd) /etc/rc.d/init.d/xinetd
[PST Dec 20 11:28:46] stop: (gpm) /etc/rc.d/init.d/gpm
[PST Dec 20 11:28:47] start: (sshd) /etc/rc.d/init.d/sshd
[PST Dec 20 11:28:48] start: (xinetd) /etc/rc.d/init.d/xinetd
[PST Dec 20 11:28:49] start: (gpm) /etc/rc.d/init.d/gpm

which has the order of gpm and xinetd flipped. I'll take a look at this
a little later this afternoon if I don't hear back.

check sshd with pidfile /var/run/sshd.pid
start program = "/etc/rc.d/init.d/sshd start"
stop  program = "/etc/rc.d/init.d/sshd stop"

check gpm with pidfile /var/run/gpm.pid
start program = "/etc/rc.d/init.d/gpm start"
stop  program = "/etc/rc.d/init.d/gpm stop"
depends on xinetd

check xinetd with pidfile /var/run/xinetd.pid
start program = "/etc/rc.d/init.d/xinetd start"
stop  program = "/etc/rc.d/init.d/xinetd stop"
depends on sshd

On Fri, 2002-12-20 at 10:06, Jan-Henrik Haukeland wrote:
> <address@hidden> writes:
> 
> > After poking around, I think the following is the best course of
> > action...
> > 
> > Revert to the old code, and then, regardless of whether we revert or
> > not, make the following changes: 1) Change the syntax to "depends"
> > and add noise word "on", so we can have
> > 
> > check foo
> > depends on bar
> > 
> > so it's nice and clear
> 
> depend is changed to depends in the new check-in. Yesterdays check-in
> had a bug with regards to the do_validate flag as you rightly pointed
> out. But I have worked some more with the depend stuff today and I
> hope it's nailed now. IMHO I think the new code works better since it
> actually traverse the dependency graph and restart entries when they
> should be restarted. I have also cleaned up the code a bit. All in all
> I advise strongly that we stay with the new implementaion unless
> serious problems should pop-up, which I don't think.
-- 
Rory Toma               address@hidden
VP of Run Level 5       http://www.trs80.net
Digeo Digital           http://www.digeo.com

signature.asc
Description: This is a digitally signed message part