System stopped routing calls until Asterisk service restart

[newguise]

We are running Asterisk 1.8.20.0 as part of Elastix 2.4.0-1. Today Asterisk completely stopped routing calls. No calls could be made or received. An attempt to dial from a registered SIP extensions would eventually time out. We restarted the Asterisk service and the system started working again normally.
The problem coincided with an update being made to the PBX configuration via the Elastix web GUI. The operation that was being performed was adding an extension to several queues. The changes were made by repeatedly clicking the “Apply Configuration Changes Here” link after each queue was changed, instead of just once to apply the complete set of changes with one reload operation. This may have been done several times within the space of a couple of minutes. The Asterisk log did contain 2 lines showing “loader.c: The previous reload command didn't finish yet”, but these were logged a couple of minutes after the issue started. When the service was restarted, it logged “asterisk.c: Asterisk uncleanly ending (0).”
I can paste a more extensive extract from the log if required.
Any advice on identifying what might have caused this and correcting the root cause would be much appreciated.
Thanks in advance.

[navaismo]

You should ask to the elastix forum since Elastix/FreePBX do more stuff and the GUI handle the configs. usually you press the "Apply Config" button once you finished all your chenges not one by one. By pressing thet button the gui send a "reload" command to asterisk and thats not the better idea but is just like it works the FPBX framework.

I guess your system get stuck with too many reloads to do. If your system its ok now try from linux shell the command: amportal stop and wiat for the confirmation then amportal start.

If issue persist check also your dns, SIP has some issues when there is no intenert connection and you can't resolve names.

[newguise]

Thanks for your reply, Navaismo. I agree that subjecting Asterisk to too many consecutive reloads is the only obvious explanation. The system has been fine since, so I won't run the amportal command unless I encounter further issues.