[Linux-ha-dev] Dynamic Modify the timeout values
d.matuda at gmail.com
Fri Aug 10 00:32:50 MDT 2007
> >>> Hi, All
> >>> I add the new function for heartbeat-2.0.8 and attached its patch file.
> >>> The function is to apply the new timeout parameters ( keepalive,
> >>> deadtime, deadping, warntime ) without stopping the heartbeat services.
> >>> Currently heartbeat boot scripts supply the 'reload' or 'forcereload'
> >>> function, but it, they are same, does stop the services and the HA
> >>> services are moved to standby node, because its process kills the forked
> >>> heartbeat processes and clients ( crmd etc. ).
> >>> So, we think to without suspending the services make the changing
> >>> parameters to apply to driving nodes. Current feature is following.
> >>> 1. changing ha.cf <http://ha.cf> file for 4 parameters
> >>> 2. send working parent heartbeat process signal SIGRTMAX ( e.g. kill -s
> >>> SIGRTMAX `cat /var/run/heartbeat.pid` (Why do I choose SIGRTMAX? I do
> >>> not find the unused good signal.)
> >>> As we research the heatbeat, it may be safety. And I want to listen to
> >>> your issues for patch and functions.
> >> Sorry to be coming in so late on this, but I was working on the release
> >> for many weeks now. I really like the idea of dynamically modifying the
> >> heartbeat configuration - but if you're going to go to the trouble to do
> >> it, I'd like to see it done more generally.
> >> In other words, I'd like to be able to change nearly any parameter in
> >> ha.cf at run time without restarting heartbeat.
> >> This would require reworking (and improving) the way heartbeat starts
> >> up. This would be probably about twice or three times as much work as
> >> what you've done, but it would be much more useful, and much more general.
> >> In the end, if done right, it could be groundwork to letting let us
> >> eventually be able receive config updates from the CIB. [I know there's
> >> a bootstrapping issue, but we can deal with that when we get to deciding
> >> to do that work].
> >> I have thought about this and have some specific ideas on what kinds of
> >> things need to be done to make this happen.
> > Hi, Alan.
> > I understood what you say and think it is very good idea to tread all
> > parameters in ha.cf. I thought my implementation is for testing and it
> > is better that you, ha-dev team, make its feature.
> I don't know quite what you meant by "it is better that you, ha-dev
> team, make it's feature".
I am sorry for poor English. It means that the feature you think to
make is better than what I made.
If possible, could you show the schedule
More information about the Linux-HA-Dev