Re: [Linux-ha-dev] Dynamic Modify the timeout values
Hi, Alan-san. I am sorry for delay. And we asked our sponsor and he admit to research what you suggest. Though I researched the parameters for ha.cf, they are over 50 and I think that almost parameters are not needed to be modified dynamically, e.g. crm, use_logd, baud, etc. So, your issue is ideally, but to realize it takes many costs and it is not pratical. I'm sorry that you view it this way. It is _certainly_ not 50 times harder than what you've done. It is probably 3-5 times harder than what you've done. Most of the work would be very simple - keeping a copy of the configuration in memory, and restructuring the while loops. And, for any parameter you could imagine, someone has at some time wanted to change it at run time without a complete restart. Especially people have asked for the ability change communications setup - especially add ucast media - at run time. People have also asked to recover from communication child processes which die - and a similar restructuring is necessary for this case. These are the harder cases - and the most useful cases. I know of very strong and common use cases for these situations. I still don't understand the use case for the change you want to make. We certainly can't add a new signal for each type of parameter we want to change. Since that's the case, I don't want to add a new signal for a single case - because that's not a general approach. What I mean by use case is this - Why does someone want (need) to change the heartbeat interval, dead time, warn time, etc. at run time? What brings that about and makes it a common thing to want to do? '50' means not working volume time but parameter numbers for ha.cf. But I cat not imagine what you say to make like the framework for dynamic changing. In the bottom, to try to change a parameter dynamically someone has to research the parameter's influence and I feel that there is no necessity to enable to change all parameters. ( I want to hear others' issue for this point. ) And I do not adhere to the signal. My patch files are just sample and if you have better way, you may suggest or apply it. Best Regards MATSUDA, Daiki ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Dynamic Modify the timeout values
DAIKI MATSUDA wrote: DAIKI MATSUDA wrote: 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 Not a problem. This will all work out. I don't have a particular schedule in mind. I'm also not sure how long it will take, and this kind of thing depends a lot on how well the person doing the change knows the code. Here is a suggested approach. At each stage, please test the patch some, submit the patch for review and then test it extensively, and submit it for re-review if you found more bugs. I would suggest in this order - to keep you from spending too much time testing a patch we ask you to do over. In fact, on the first stage maybe review your data structures first, because that will determine the code in the end. Step 1 - Further categorize and modularize the configuration. There are at least 4 kinds of statements in the configuration and there may be more: 1. media statements - like ucast, bcast, etc. Things which load plugins and start read/write processes 2. global statements - which affect some or all of the media statements - things like port number, serial baud rate, etc. Knowing which global statements affect which media statements, may eventually be important. 3. Respawn statements - things which start child processes this includes the implied respawn statements in things like 'crm on'. 4. Other statements. For each of these, figure out which class of processes are affected by each change. Make it so that each media statement is processed by a single function call. Right now, the processing for any given media statement is embedded in a loop. This is just restructuring. If you store all the ha.cf statements in an array, then you can make a minor improvement even in this stage. Make a pass through the array looking for global statements and execute them first. This will fix some known annoying behaviors where these need to occur before they're used. For media and respawn statements, you need to add an association between the statements and the child processes they created. That way, when we finally get around to processing changes, we can kill them when they go away or change. We already have a special way to track processes. Use that code, but create new associations. Note that this doesn't implement the feature we are talking about, it just lays the groundwork for it. At this point the code won't be able to do
Re: [Linux-ha-dev] Dynamic Modify the timeout values
DAIKI MATSUDA wrote: 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 Not a problem. This will all work out. I don't have a particular schedule in mind. I'm also not sure how long it will take, and this kind of thing depends a lot on how well the person doing the change knows the code. Here is a suggested approach. At each stage, please test the patch some, submit the patch for review and then test it extensively, and submit it for re-review if you found more bugs. I would suggest in this order - to keep you from spending too much time testing a patch we ask you to do over. In fact, on the first stage maybe review your data structures first, because that will determine the code in the end. Step 1 - Further categorize and modularize the configuration. There are at least 4 kinds of statements in the configuration and there may be more: 1. media statements - like ucast, bcast, etc. Things which load plugins and start read/write processes 2. global statements - which affect some or all of the media statements - things like port number, serial baud rate, etc. Knowing which global statements affect which media statements, may eventually be important. 3. Respawn statements - things which start child processes this includes the implied respawn statements in things like 'crm on'. 4. Other statements. For each of these, figure out which class of processes are affected by each change. Make it so that each media statement is processed by a single function call. Right now, the processing for any given media statement is embedded in a loop. This is just restructuring. If you store all the ha.cf statements in an array, then you can make a minor improvement even in this stage. Make a pass through the array looking for global statements and execute them first. This will fix some known annoying behaviors where these need to occur before they're used. For media and respawn statements, you need to add an association between the statements and the child processes they created. That way, when we finally get around to processing changes, we can kill them when they go away or change. We already have a special way to track processes. Use that code, but create new associations. Note that this doesn't implement the feature we are talking
Re: [Linux-ha-dev] Dynamic Modify the timeout values
DAIKI MATSUDA wrote: 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 Not a problem. This will all work out. I don't have a particular schedule in mind. I'm also not sure how long it will take, and this kind of thing depends a lot on how well the person doing the change knows the code. Here is a suggested approach. At each stage, please test the patch some, submit the patch for review and then test it extensively, and submit it for re-review if you found more bugs. I would suggest in this order - to keep you from spending too much time testing a patch we ask you to do over. In fact, on the first stage maybe review your data structures first, because that will determine the code in the end. Step 1 - Further categorize and modularize the configuration. There are at least 4 kinds of statements in the configuration and there may be more: 1. media statements - like ucast, bcast, etc. Things which load plugins and start read/write processes 2. global statements - which affect some or all of the media statements - things like port number, serial baud rate, etc. Knowing which global statements affect which media statements, may eventually be important. 3. Respawn statements - things which start child processes this includes the implied respawn statements in things like 'crm on'. 4. Other statements. For each of these, figure out which class of processes are affected by each change. Make it so that each media statement is processed by a single function call. Right now, the processing for any given media statement is embedded in a loop. This is just restructuring. If you store all the ha.cf statements in an array, then you can make a minor improvement even in this stage. Make a pass through the array looking for global statements and execute them first. This will fix some known annoying behaviors where these need to occur before they're used. For media and respawn statements, you need to add an association between the statements and the child processes they created. That way, when we finally get around to processing changes, we can kill them when they go away or change. We already have a special way to track processes. Use that code, but create new associations. Note that this doesn't implement the feature we are talking about, it just lays the groundwork for it. At this point the code won't be
Re: [Linux-ha-dev] Dynamic Modify the timeout values
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 Best Regards MATSUDA, Daiki ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Dynamic Modify the timeout values
DAIKI MATSUDA wrote: 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. -- Alan Robertson [EMAIL PROTECTED] Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions. - William Wilberforce ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Dynamic Modify the timeout values
DAIKI MATSUDA wrote: 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. -- Alan Robertson [EMAIL PROTECTED] Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions. - William Wilberforce ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Dynamic Modify the timeout values
On Thu, Jul 26, 2007 at 06:44:21PM +0200, Lars Marowsky-Bree wrote: On 2007-07-26T15:52:00, Horms [EMAIL PROTECTED] wrote: There really are systems out there running linux-ha that don't have bash. For instance, some Debian systems have dash installed not bash. It is true that bash's kill allows SIGRTMAX while /bin/kill does not. But I think we should look for another solution. Here are some ideas that I have. Simply add a requirement for bash to the heartbeat package and be done with this. A number of RAs require bash as well. FYI, I posted a patch to make this change and was pointed to a discussion on this issue going on in bugzulla. http://old.linux-foundation.org/developer_bugzilla/show_bug.cgi?id=1670 -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Dynamic Modify the timeout values
On Wed, Jul 25, 2007 at 01:31:11PM +0900, DAIKI MATSUDA wrote: Hello, All. I post patch files again, because I added a new feature to send the modified timeout values to other nodes. Its description is at the bottom. I could make the nodes that received the message over-write the ha.cf file. But I feel that it is meddlesome and I implemented the all required features by this patch. And I attach all patch files because after posting the previous e-mail I have fixed some bugs. 6_send_values_to_cluster.patch: This patch is to send modified timeout values to the other nodes with the existing communication channel. The node that received a signal SIGRTMAX sends a message for the other nodes. They receive message, decode it to know the new timeout values and try to reflect them. Best Regards MATSUDA, Daiki Hi Matsuda-san, sorry for taking so long to reply again. I've taken a look over these patches, and they seem to be looking quite good. There is still quite a lot of material, so I am sure that there are some things that I have missed. bUt here are my comments for now. I think that the patches need to be reordered. I found that with a small ammount of rediffing of the hb_config.h fragements, the flolowing order worked: 1_remember_timeout_to_array.patch 4_apply_modified_value.patch 3_add_parse_function.patch 2_add_signal_handler.patch 5_send_keepalive_to_ccm.patch 6_send_values_to_cluster.patch 6_send_values_to_cluster-fix.patch The original order did not work as 2_add_signal_handler.patch requires light_parse_config(), which is provided by 3_add_parse_function.patch, and 3_add_parse_function.patch requires modify_keepalive_value() and modify_deadtime_value() which are provided by 4_apply_modified_value.patch Hi, Horms-san. Thank you for reply and sorry for confusing by similar name patches. I attached the re-made patches with references of your suggestion. They can be applied to heartbeat-2.1.1 and works well. And I answer about important question. Hi Matsuda-san, thanks for cleaning up the patches and addressing my questions. I only have two problems left. 1. patch order (very minor) The patches need to be in the following order. You can see why if you try to compile with only patches 1 2 or only patches 1, 2 3 applied. The patches 3 and 4 need minor modifications to the hb_config.h hunk in order to apply cleanly in the new order. 1_remember_timeout_to_array_20070725.patch 4_apply_modified_value_20070725.patch 3_add_parse_function_20070725.patch 2_add_signal_handler_20070725.patch 5_send_keepalive_to_ccm_20070725.patch 6_send_values_to_cluster_20070725.patch 2. bash vs sh Its been the policy of linux-ha for a long time to use sh instead of bash. I know that there are sometimes good reasons to use bash, but so far the project has been successful in only using sh. There really are systems out there running linux-ha that don't have bash. For instance, some Debian systems have dash installed not bash. It is true that bash's kill allows SIGRTMAX while /bin/kill does not. But I think we should look for another solution. Here are some ideas that I have. 1. Use pkill. Is this on all platforms that linux-ha supports? 2. Choose another signal. But I don't think there are any good candidates. 3. Write a simple ha_kill command in C. This should be easy enough. 4. Signal the running process in a different way. Perhaps through the API. But this is probably very heavy. I think that I like 1 and 3 the best. But perhaps there are better ideas. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Dynamic Modify the timeout values
On 2007-07-26T15:52:00, Horms [EMAIL PROTECTED] wrote: There really are systems out there running linux-ha that don't have bash. For instance, some Debian systems have dash installed not bash. It is true that bash's kill allows SIGRTMAX while /bin/kill does not. But I think we should look for another solution. Here are some ideas that I have. Simply add a requirement for bash to the heartbeat package and be done with this. A number of RAs require bash as well. ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Dynamic Modify the timeout values
On Wed, Jul 04, 2007 at 04:20:49PM +0900, DAIKI MATSUDA wrote:
Hello, All.
I post patch files again, because I added a new feature to send the
modified timeout values to other nodes. Its description is at the
bottom. I could make the nodes that received the message over-write
the ha.cf file. But I feel that it is meddlesome and I implemented the
all required features by this patch.
And I attach all patch files because after posting the previous e-mail
I have fixed some bugs.
6_send_values_to_cluster.patch:
This patch is to send modified timeout values to the other nodes with
the existing communication channel. The node that received a signal
SIGRTMAX sends a message for the other nodes. They receive message,
decode it to know the new timeout values and try to reflect them.
Best Regards
MATSUDA, Daiki
Hi Matsuda-san,
sorry for taking so long to reply again. I've taken a look over these
patches, and they seem to be looking quite good. There is still quite a
lot of material, so I am sure that there are some things that I have
missed. bUt here are my comments for now.
I think that the patches need to be reordered. I found that with a small
ammount of rediffing of the hb_config.h fragements, the flolowing order
worked:
1_remember_timeout_to_array.patch
4_apply_modified_value.patch
3_add_parse_function.patch
2_add_signal_handler.patch
5_send_keepalive_to_ccm.patch
6_send_values_to_cluster.patch
6_send_values_to_cluster-fix.patch
The original order did not work as 2_add_signal_handler.patch requires
light_parse_config(), which is provided by 3_add_parse_function.patch,
and 3_add_parse_function.patch requires modify_keepalive_value() and
modify_deadtime_value() which are provided by 4_apply_modified_value.patch
*
*** 1_remember_timeout_to_array.patch ***
*
diff -uNrp heartbeat-2.0.8.orig/heartbeat/hb_api.c
heartbeat-2.0.8_1/heartbeat/hb_api.c
--- heartbeat-2.0.8.orig/heartbeat/hb_api.c 2007-01-12 11:57:05.0
+0900
+++ heartbeat-2.0.8_1/heartbeat/hb_api.c 2007-06-27 08:32:17.0
+0900
@@ -1291,6 +1291,10 @@ process_registerevent(IPC_Channel* chan,
, client, G_remove_client);
G_main_setdescription((GSource*)client-gsource, API client);
G_main_setmaxdispatchdelay((GSource*)client-gsource,
config-heartbeat_ms);
+
+ maxdispatchdelay_array_add((void*)(client-gsource), KEEPALIVE_TYPE
+ , '*', 1, 0);
+
G_main_setmaxdispatchtime((GSource*)client-gsource, 100);
if (ANYDEBUG) {
cl_log(LOG_DEBUG
diff -uNrp heartbeat-2.0.8.orig/heartbeat/hb_config.h
heartbeat-2.0.8_1/heartbeat/hb_config.h
--- heartbeat-2.0.8.orig/heartbeat/hb_config.h2007-01-12
11:57:05.0 +0900
+++ heartbeat-2.0.8_1/heartbeat/hb_config.h 2007-06-27 08:32:17.0
+0900
@@ -31,5 +31,26 @@ intparse_authfile(void);
int init_config(const char * cfgfile);
int StringToBaud(const char * baudstr);
const char * GetParameterValue(const char * name);
+/*
+ maxdispatchdelay_array_add is to memory the behaviour the function
+ * G_main_setmaxdispatchdelay((GSource*)addr, config-deadtime_ms/value);
+ * type: heartbeat_ms -KEEPALIVE_TYPE
+ * deadtime_ms - DEADTIME_TYPE
+ * warntime_ms - WARNTIME_TYPE
+ * deadping_ms - DEADPING_TYPE
+ *
+ * mode: * - '*'
+ * / - '/'
+ */
/* maxdispatchdelay_array_add() records calls to G_main_setmaxdispatchdelay()
* so that is can be called once again if the base timeout is updated.
*
* Calls to G_main_setmaxdispatchdelay() are of the form
* G_main_setmaxdispatchdelay((GSource*)addr, config-deadtime_ms / value);
* or
* G_main_setmaxdispatchdelay((GSource*)addr, config-deadtime_ms * value);
*
* addr:
* GSource addr ass passed as the first argument of
* G_main_setmaxdispatchdelay()
*
* type:
* The type argument to maxdispatchdelay_array_add() denotes which
* element of config is being used as the base value for the timeout
*
* KEEPALIVE_TYPE: config-heartbeat_ms
* DEADTIME_TYPE: config-deadtime_ms
* WARNTIME_TYPE: config-warntime_ms
* DEADPING_TYPE: config-deadping_ms
*
* mode:
* The mode specifies the operation that should occur on the
* base timeout value
*
* '*': multiplication
* '/': division
*
* value:
* The value to apply to the base timeout using the mode
*
* pid:
* Pid of the process that is being effected
*/
I wonder if it would be better to use an enum for mode.
+void maxdispatchdelay_array_add(void *addr, int type, char mode, int
value, pid_t pid);
+/*
+ * setall_array_add is to memory the behaviour the function
+ * G_main_setall_id(id, foo, config-warntime_ms/2+10, num);
+ * type: same as maxdispatchdelay_array_add
+ * calc: cl_strdup(/ 2 + 10)
+ * must insert whitespace between numbers and operands
+ *
Re: [Linux-ha-dev] Dynamic Modify the timeout values
Hello, All.
Some days ago I sent the patch that offer the function to apply the
timeout values without suspending the heartbeat service. Then
Horms-san suggested me to modify it. So, I re-make and attach. The
Attached patches should be applied from 1_... to 5_...
Additionally some other bugs are fixed, including:
1. When clients did signoff the communication channel, its pointer was
removed. But maxdispatchdelay_array remembered it and
modify_setmaxdispatchdelay_value() accessed it.
2. As g_ptr_array_free() removed the pointers included its elements,
the communication channel vanished. So when heartbeat was shutdown, it
could not kill some clients.
And I note the additional information as following,
1. I am testing on the dev source tree now simply and works well.
Attached the patches can be applied to the 5bb25d3ce208 source tree.
2. Though I am suggested to use modify_keepalive_value() in both
startup and modify cases, I do not do so.
I cleaned it up. But there are no functional changes from the previous
version of the patch. (except init scripts and bug fixes?) So if you
send the signal (SIGRTMAX) to a server, the values are effective for
the server and do not transmit to the other servers. But by adding the
function to communicate to other servers, such as HBDoMsg_T_STATUS(),
I think that it is possible to do.
Followings are the description for the patch files.
1_record_timeout_to_array.patch:
This patch is for the 3 tables, maxdispatchdelay_array, setall_array
and timeout_add_full_array. They are for remembering the behaviour of
the functions, G_main_set_maxdispatchdelay(), G_main_setall_id() and
Gmain_timeout_add_full(), because they use the values generated by the
timeout values or equal to the timeouts values. I choose the Glib
functions for them as same as the original codes.
2_add_signal_handler.patch:
This patch adds the function to handle the signal SIGRTMAX. I think
that it is good to use the signal for applying the values, because
current reload function use the SIGHUP signal. There was no
modification for init script files in the previous patch, but this
time patch includes the option 'light-reload' and 'lread'.
3_add_parse_fucntion.patch:
This patch is written for the behaviour after receiving the signal,
especially parsing the ha.cf configuration file. As previous pointed,
the light_parse_config() function is adjusted to the parse_config().
4_apply_modified_value.patch:
This patch is written for after receiving the signal, too. Especially,
for applying the variables the values actually.
5_send_keepalive_to_ccm.patch:
This patch is for sending the keepalive value for ccm. To do so it
uses the existing communication channel. Maybe this is not enough
clean.
I want to listen to your advice for the function, the patch and etc.
Best Regards
MATSUDA, Daiki
diff -uNrp heartbeat-2.0.8.orig/heartbeat/hb_api.c heartbeat-2.0.8_1/heartbeat/hb_api.c
--- heartbeat-2.0.8.orig/heartbeat/hb_api.c 2007-01-12 11:57:05.0 +0900
+++ heartbeat-2.0.8_1/heartbeat/hb_api.c 2007-06-27 08:32:17.0 +0900
@@ -1291,6 +1291,10 @@ process_registerevent(IPC_Channel* chan,
, client, G_remove_client);
G_main_setdescription((GSource*)client-gsource, API client);
G_main_setmaxdispatchdelay((GSource*)client-gsource, config-heartbeat_ms);
+
+ maxdispatchdelay_array_add((void*)(client-gsource), KEEPALIVE_TYPE
+ , '*', 1, 0);
+
G_main_setmaxdispatchtime((GSource*)client-gsource, 100);
if (ANYDEBUG) {
cl_log(LOG_DEBUG
diff -uNrp heartbeat-2.0.8.orig/heartbeat/hb_config.h heartbeat-2.0.8_1/heartbeat/hb_config.h
--- heartbeat-2.0.8.orig/heartbeat/hb_config.h 2007-01-12 11:57:05.0 +0900
+++ heartbeat-2.0.8_1/heartbeat/hb_config.h 2007-06-27 08:32:17.0 +0900
@@ -31,5 +31,26 @@ int parse_authfile(void);
int init_config(const char * cfgfile);
int StringToBaud(const char * baudstr);
const char * GetParameterValue(const char * name);
+/*
+ maxdispatchdelay_array_add is to memory the behaviour the function
+ * G_main_setmaxdispatchdelay((GSource*)addr, config-deadtime_ms/value);
+ * type: heartbeat_ms -KEEPALIVE_TYPE
+ * deadtime_ms - DEADTIME_TYPE
+ * warntime_ms - WARNTIME_TYPE
+ * deadping_ms - DEADPING_TYPE
+ *
+ * mode: * - '*'
+ * / - '/'
+ */
+void maxdispatchdelay_array_add(void *addr, int type, char mode, int value, pid_t pid);
+/*
+ * setall_array_add is to memory the behaviour the function
+ * G_main_setall_id(id, foo, config-warntime_ms/2+10, num);
+ * type: same as maxdispatchdelay_array_add
+ * calc: cl_strdup(/ 2 + 10)
+ * must insert whitespace between numbers and operands
+ * only +, -, * and / are admitted as operands
+ */
+void setall_array_add(long id, int type, char * calc);
#endif /* _HB_CONFIG_H */
diff -uNrp heartbeat-2.0.8.orig/heartbeat/hb_rexmit.c heartbeat-2.0.8_1/heartbeat/hb_rexmit.c
--- heartbeat-2.0.8.orig/heartbeat/hb_rexmit.c 2007-01-12 11:57:05.0 +0900
+++
Re: [Linux-ha-dev] Dynamic Modify the timeout values
Dear All. I am sorry for sending a little break patch by previous e-mail. So, I re-send 2_add_signal_handler.patch and 3_add_parse_fucntion.patch, and please replace. Best Regards MATSUDA, Daiki 2007/6/27, DAIKI MATSUDA [EMAIL PROTECTED]: Hello, All. Some days ago I sent the patch that offer the function to apply the timeout values without suspending the heartbeat service. Then Horms-san suggested me to modify it. So, I re-make and attach. The Attached patches should be applied from 1_... to 5_... Additionally some other bugs are fixed, including: 1. When clients did signoff the communication channel, its pointer was removed. But maxdispatchdelay_array remembered it and modify_setmaxdispatchdelay_value() accessed it. 2. As g_ptr_array_free() removed the pointers included its elements, the communication channel vanished. So when heartbeat was shutdown, it could not kill some clients. And I note the additional information as following, 1. I am testing on the dev source tree now simply and works well. Attached the patches can be applied to the 5bb25d3ce208 source tree. 2. Though I am suggested to use modify_keepalive_value() in both startup and modify cases, I do not do so. I cleaned it up. But there are no functional changes from the previous version of the patch. (except init scripts and bug fixes?) So if you send the signal (SIGRTMAX) to a server, the values are effective for the server and do not transmit to the other servers. But by adding the function to communicate to other servers, such as HBDoMsg_T_STATUS(), I think that it is possible to do. Followings are the description for the patch files. 1_record_timeout_to_array.patch: This patch is for the 3 tables, maxdispatchdelay_array, setall_array and timeout_add_full_array. They are for remembering the behaviour of the functions, G_main_set_maxdispatchdelay(), G_main_setall_id() and Gmain_timeout_add_full(), because they use the values generated by the timeout values or equal to the timeouts values. I choose the Glib functions for them as same as the original codes. 2_add_signal_handler.patch: This patch adds the function to handle the signal SIGRTMAX. I think that it is good to use the signal for applying the values, because current reload function use the SIGHUP signal. There was no modification for init script files in the previous patch, but this time patch includes the option 'light-reload' and 'lread'. 3_add_parse_fucntion.patch: This patch is written for the behaviour after receiving the signal, especially parsing the ha.cf configuration file. As previous pointed, the light_parse_config() function is adjusted to the parse_config(). 4_apply_modified_value.patch: This patch is written for after receiving the signal, too. Especially, for applying the variables the values actually. 5_send_keepalive_to_ccm.patch: This patch is for sending the keepalive value for ccm. To do so it uses the existing communication channel. Maybe this is not enough clean. I want to listen to your advice for the function, the patch and etc. Best Regards MATSUDA, Daiki 2_add_signal_handler.patch.new Description: Binary data 3_add_parse_fucntion.patch.new Description: Binary data ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Dynamic Modify the timeout values
Hi Horms, On Thu, Jun 21, 2007 at 12:36:02PM +0900, Horms wrote: [snip] Also, I'm not a big fan of declaring variables other inside blocks, but I'm not sure what the linux-ha guidelines on this are. Often, I find it preferable. If the function is long,* tracing a variable which has nothing to do with the rest of the code, and so on, you get the point. Why is it that you don't like it? Cheers, Dejan *) Though, functions really should not be that long. ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
