its supposed to be optional to disable them, atleast thats what alex said he was going to implement; and no, its not better to let the tenant admins do their own reloads. You must be on a rather small setup if this problem has not occurred for you... After about 400 or so tenants we started getting reloads so frequent that we had one reload after another and I was hearing reports of even larger systems experiencing crashes due to too many subsequent reloads. I was looking into the option to disable tenant admin reloads so that one could set up a CRON job to initiate reloads every 15min. In that situation no reload would occur any more frequent and someone would just wait till the next quarter hour mark to see their changes go live.

a script executable by crontab

we've only got 20 tenants so far on this system.

(just starting :)

cron is fine by me.

Hmm, that's 400 very active tenants you're hosting. Mostly it's changes in the initial phase here and I've drilled it into the delegated admins they should only do a reload after all the changes they planned have been entered. But indeed, if asterisk gets reloaded every min or so, it won't help matters :)

Is this new feature likely to be changed either back to what it was originally or as an optional tick box under the administrator settings?

This is causing me complaints from my customers and i dont want an auto reload in the background as sometimes we make changes that we do not want to trigger untill all of our planned changes are made. (I realise there could be a risk of this happening if a customer changes something and issues a restart themselves).

This was an unexpected change - we would like the reload button back. Maybe it could be made so, that reloads can only happen every 5 minutes (or what ever you specify). If a reload has just occurred and a new one is issued - the new one is postponed till the next timeslot.

We (our customers) don't change settings that often - but it is important for them that the changes are (close to) instant. Another problem is that iSymphony drops the connection to the client on each reload. We have notified i9 about this - but no answer yet. Until that is solved, cronjob thingy is not a good idea.

/Ole

umm your statement makes no sense what so ever... how can reloading at the max of ever 15min be WORSE than reloading constantly? Its not like its going to reload every 15min even when there is no pending reload. If you are worried about reloads dropping isymphony then you have MORE of a reason to take away the reload button than others. As far as frequency, you can make the cron job check ever 5 minutes if you want. Do you know how to read bash conditionals?

if [ -e /etc/webmin/asterisk/reload_default ]

To the bash shell it says 'if the file if /etc/webmin/asterisk/reload_default exists return true'. This file is the _exact same file_ webmin uses to present the reload link. No change to the configs means no file when the cron job runs, which means no reload.

Web pages are event driven programming, not daemons listening for time slots. Its far easier to use cron to manage time events than to try and turn a website into something it cant be.

on busier systems reloads are responsible for dropped calls, asterisk crashes, even call setup delays that have been as extreme as a timeout failure. This must be mitigated to deal with these issues. Other methods are also being devised to reduce the time to perform a reload on systems with large amount of extensions and tenants.

there is an 'instant resolution' option still available to those running tiny setups. The option under 'System Settings -> Preferences' labeled 'Issue reload after every change'. If you have a small scale system and want immediate results, you should use this option.

Sorry Erik, I didn't read what your bash script does. The cronjob makes more sense now, as reloads are only done if needed. My concern was that I was guaranteed a reload (and disconnct of isym.) every 15 minutes instead of a few random reloads during the busy hours. Most of our customers let us do the (advanced) editing, and limit the changes done by them selves to schedules and toggling members in huntlists. Most of this is done in the morning or the afternoon. Anyway, I asked i9 about this and after only two days I got an answer. It was already there - just uncheck the 'reload' check box on the tenant (duh!). I have yet to discover what ill effect unchecking that, migth have... but I better schedule a restart of isymphony every night.

In the beginning we had the 'Issue reload after every change' option checked (why not!). After some time asterisk started to act up, crash, fire, judgement day, angry customers (oh - thats why!). So, fine for convenience - nothing else.

/Ole

Hmmm... with a little tweaking the script can be a one liner that can be dropped rigth into crontab like this:

I can recommend the Advanced Bash-Scripting Guide:

http://www.tldp.org/LDP/abs/html/

/Ole

Eric

Can you comment if this feature will be optional in the next release and if so when will that be?

regards

Gert

it already is,

System Settings -> Preferences

Issue reload after every change Yes/No

Hi Eric

I understand, but i ment the option to manualy give a reload for non admins

Gert

Run the cron job every minute instead. Your average wait time will be 30 seconds. Since Asterisk is a bit itchy about frequent reloads, I think this would be better than by coincidence having 10 admins hitting the reload button within 2 minutes time frame. Remember, the cronjob only reloads when needed.

/Ole

Erik, I like the cron job idea, but I can't get version 6.0.1.74 to stop reloading automatically. I don't see Preferences under System Settings. I have confirmed that it is doing an automatic reload when I save a setting in Thirdlane.

log back in as root, only root can see preferences (no idea why, seems kinda dumb)

I guess that's so that a customer can't set it back to reload.

maybe, but if you set a system admin called Admin who can see and do everything... he can't see the preferences page.

You can add permission to access Preferences page by setting on Can edit module configuration? in the Webmin -> Webmin Users -> select the user -> select Thirdlane PBX Manager -> check Can edit module configuration on the top of the page. I would be careful though.

I need it for myself, often I sell a system where the customer wants to change root access logins but we retain a different login into pbxmanager and into a bash shell. This was the one place we could never get to without a root login.

i have added the script that checks if there is a reload neccesery and made it check every 5 min, would be nice if this could be included into thirdlane, and instead of a reload butten there would appear a timer when somebody makes a change witch says howlong til the next reload

web pages are event driven applications not running daemons. We are also looking into module specific reloads instead of a generic 'reload' (example: dialplan reload, sip reload, iax2 reload, reload app_voicemail.so, etc). This will change the script considerably I am sure.

A generic 'reload' is having a disastrous impact on modules that use counters such as queue strategies. any time that the queue module reloads all the counters reset so strategies like fewest calls, least recent, rrmemory, etc. start going haywire and have to start over again defeating their purpose.

expect a near future change requiring modification to the cron script that issues the reload.