Skip to main content

\Disabled reload for non system level administrators"rather inconvenient in MTE"""

Posted by albert@netwizard.nl on Tue, 08/11/2009

A customer reported some strange behavior which after some digging around could be traced to the fact that his changes weren't applied, mostly because he didn't see the 'reload PBX' link and we haven't enabled automatically reloading after changes.
In the 6.0.1.73 changelog I see that the reload PBX for 'non system level admins' has been disabled.
That's rather inconvenient for the MTE. I can't possibly login myself everytime one of the tenants make some changes and I can't give them full access either now can I ?

Isn't better to give an administrator "reload rights" ?

Cheers


Submitted by eeman on Tue, 08/11/2009 Permalink

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.

Submitted by eeman on Tue, 08/11/2009 Permalink

a script executable by crontab

#!/bin/bash

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

asterisk -rx "reload";

rm /etc/webmin/asterisk/reload_default;

fi

Submitted by albert@netwizard.nl on Tue, 08/11/2009 Permalink

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 :)

Submitted by isrighthere on Wed, 09/16/2009 Permalink

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).

Submitted by olekaas on Thu, 10/01/2009 Permalink

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

Submitted by eeman on Thu, 10/01/2009 Permalink

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.

Submitted by olekaas on Fri, 10/02/2009 Permalink

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

Submitted by olekaas on Fri, 10/02/2009 Permalink

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

*/10 * * * [ -e /etc/webmin/asterisk/reload_default ] && /usr/sbin/asterisk -r -x "reload" && /bin/rm /etc/webmin/asterisk/reload_default

I can recommend the Advanced Bash-Scripting Guide:

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

/Ole

Submitted by gerteizinga on Tue, 10/06/2009 Permalink

Eric

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

regards

Gert

Submitted by olekaas on Wed, 10/07/2009 Permalink

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

Submitted by dozment on Wed, 10/07/2009 Permalink

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.

Submitted by thirdlane on Tue, 10/13/2009 Permalink

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.

Submitted by eeman on Tue, 10/13/2009 Permalink

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.

Submitted by gerteizinga on Thu, 11/05/2009 Permalink

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

Submitted by eeman on Thu, 11/05/2009 Permalink

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.