On 2012/01/13 16:02, Peter Hessler wrote: > I would really like the feature to be available, but I agree that the > current implentation causes problems. > > The correct behaviour is +1/-1, of course.
i think the daemons should only be managing +1 (or +n) and a corresponding -1 (or -n) for things which they can detect themselves e.g. as currently done: bgpd -> session drops out. ospfd -> no active neighbours in an area. and as might make sense, relayd -> no backends for a certain service. note that if bgpd raises carpdemote due to a downed peer, it *undoes any changes it made* at exit (and this is necessary otherwise if a peer is unstable and you restart bgpd, you end up with carpdemote raising). i suspect the semantics you're actually looking for for relayd might be "if relayd is not running, carpdemote should be raised". i'd argue that this raise should not be done by relayd itself (if it blows up spectacularly it may no longer able to raise carpdemote when it dies) but by an external process, perhaps ifstated, perhaps something else. simplest might be to loop through a list of expected-to-be-active daemons (/var/run/rc.d can help with a list of these), check them with /etc/rc.d/XX status, and raise carpdemote if any are missing. (with optional alerts and/or auto-restart...) note that /etc/rc has a carpdemote interlock which is not supposed to be removed until all daemons have finished starting; the documented (but not actual) behaviour for relayd tramples on this.
