Summary:	ASTERISK-18842: text config files are treated as unchanged when changing and reloading them quickly one after another
Reporter:	Thomas Arimont (tomaso)	Labels:
Date Opened:	2011-11-09 09:35:06.000-0600	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Core/Configuration
Versions:	1.6.2.15 1.8.7.0 13.18.4	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Text config files are (can be) treated as unchanged when changing a config file and reloading it ('reload' or module reload) quickly one after another. Due to the generic implementation of the configuration loading, which was introduced somewhere in Asterisk 1.6 to increase performance, a text config file is treated as unchanged in dependency of the file modification time (to avoid unnecessary config parsing). Since the granularity of this timestamp is 1 sec fast consecutive config changes incl. reloading within this time are mostly not succesful. I've spent some time to find out what was wrong with a config script of mine ... Is there no smarter way to solve this?
Comments:	By: Walter Doekes (wdoekes) 2011-11-09 13:42:46.662-0600 There might be smarter ways to do it (e.g. more granularity). But I would rather fix the problem that causes you to have to reload a config every second. Config reloading can be quite an expensive operation. Perhaps there are cheaper ways to accomplish what you want. By: Thomas Arimont (tomaso) 2011-11-09 14:27:08.616-0600 Walter, yes, indeed config loading every second would not be a meaningful thing and that's not what we are really doing. There is one special case in our 'configurator surrounding' where we have to change a config, reload, change the config again and reload it another time. It's regarding the app_queue resp. the queues.conf configuration file: We use dynamic queue members (exclusivly) and generally want to have them persistent even after a reload (using persistentmembers parameter). The members use a special feature code to log in resp. log out which triggers the queue add or queue remove dialplan functions. However if the config-admin wants to delete a certain member from the queue (so the member is not able to login anymore), we first have to set the queues.conf persistentmember parameter to no, reload, set the queues.conf to what it was before and reload again - to get what we want. If you have another good solution for this special problem you are welcome! (The solution which we are using now to get this work with asterisk 1.8 - asterisk 1.4 was fine - is to use a pause of 1 second before rewriting the config a second time, but infact I would like to have these things going faster to approach more 'realtime configuration' - maybe I'm a little bit too perfectionistic) Regards Thomas By: Leif Madsen (lmadsen) 2011-11-10 15:21:50.163-0600 Can you elaborate on why you need to change persistentmembers at all in order to log someone out? By: Thomas Arimont (tomaso) 2011-11-14 01:45:52.752-0600 Leif, it might be a more 'historical' way how we implemented the (config) handling of queues and call groups: Generally our config-admin is able to configure waitqueues and can define the members which are allowed to login via feature code. If he wants to remove a member later setting persistentmembers to no, reloading and restoring the old queues.conf (plus reloading) seems to be the only way to get rid of the persistence of this member. Beside this special problem, we cannot really exclude the case that config changing and reloading is done quickly one after another. This is because a user (e.g. activating/deactivating call forwarding) as well as the config admin can change resp. initiate a config reload process independently. If the config change/reload process is quick enough and both processess occur almost at the same time this could make a problem too. Indeed our config change/reload process is usually taken more than one second, so this problem has not been seen yet. It might be an enhancement if at least the file size of a config file additionally is taken into account when examing if a file has changed or left unchanged. By: Walter Doekes (wdoekes) 2011-11-14 02:11:52.303-0600 > Beside this special problem [...] a user (e.g. activating/deactivating call forwarding) as > well as the config admin can change resp. initiate a config reload process independently. > If the config change/reload process is quick enough and both processess occur almost at the > same time this could make a problem too. Indeed our config change/reload process is usually > taken more than one second, so this problem has not been seen yet. While I understand that it'd be easiest for you to have it fixed at this level; I would argue that you might need a layer between your config altering process and the process of telling the new config to asterisk. (If i-already-updated-the-config-this-minute then wait-a-bit and first then update-the-config.) By: Thomas Arimont (tomaso) 2011-11-14 02:26:13.838-0600 Walter, yes, your suggested solution is what we will finally have to do (resp. have already done) to avoid problems with this changed behaviour of asterisk 1.6. Thanks a lot for you interest in this issue. Regards from Aachen/Aken Thomas By: Matt Jordan (mjordan) 2011-11-15 09:16:43.777-0600 Changing this issue from bug to feature request.  The fact that config files are tracked as being modified using timestamps with a 1 second granularity is part of the design, and is not a bug.  Changing the design to using a different mechanism would be a new feature for Asterisk.