Call extension to run "core reload"

General Help
1

I want to be able to do a “core reload” by dialling extension 301.

The script reloadasterisk.cron runs in the remote CLI with ./reloadasterisk.cron

I created a Custom Destination with target from-internal-custom,301,1
I created a Misc Application with Custom Destination, and selected the new Custom Destination.

Then in extensions_custom.conf I added:
[from-internal-custom]

exten => 301,1,NoOP
same => 301,1,System(reloadasterisk.cron)
same => n,Hangup()

(I also tried with /root/reloadasterisk.cron and ./reloadasterisk.cron)

When I dial 301 from ext 701 I get:
[2019-05-31 08:46:30] VERBOSE[17930][C-00000009] pbx_builtins.c: Goto (from-internal-custom,301,1)
[2019-05-31 08:46:30] VERBOSE[17930][C-00000009] pbx.c: Executing [301@from-internal-custom:1] NoOp(“PJSIP/701-00000009”, “”) in new stack
[2019-05-31 08:46:30] VERBOSE[17930][C-00000009] pbx.c: Auto fallthrough, channel ‘PJSIP/701-00000009’ status is ‘UNKNOWN’

The discussions elsewhere are all about permissions and the path in the config file.
However I suspect my problem starts with my extensions_custom.conf edit.

All help gratefully received.

2

To start with, you have two priority 1’s . . .

2 Likes
3

Thanks Dicko.
I think I’ve got the dialplan working. Now I need to work out how to get it to run the script.
I guess the first question is: is there a better way to get the dialplan to send “core reload”?
Or do I just need to work out how to get the path right so it runs the script? I use that script for a daily reload using cron, but I can just run it from the console by entering ./reloadasterisk.cron

4

Truthfully , here should never be a need to ever do a core reload, what did you break?

5

When my sip provider has a problem or does some maintenance, usually overnight, I always found that in the morning the registration had not come back up, which was fixed with a core reload. I am usually not at the office in the morning, and reception goes into a panic. So I do a reload via cron every morning even though usually it is redundant. But lately they’ve been having trouble during the day and same problem with registration failing while phones are in full swing. So I want to give my receptionists a push button way to fix it.

6

exten => 301,1,NoOP
same => n,System(asterisk -x “core reload”)
same => n,Hangup()

Did the job! Its always easy once you know how.

Is there anything at risk by doing a reload like that?

7

I’m glad that you got this working, but something is very wrong if a temporary network outage causes a ‘permanent’ registration failure. Asterisk should retry indefinitely.

If you can cause the trouble at will (after business hours), e.g. by disconnecting the cable from your modem, waiting a while then reconnecting it, it should not be hard to observe what goes wrong and modify configuration (in PBX, router, etc.) to be more robust. Even if you can’t, adding additional logging (or a more thorough analysis of existing logs) should allow you to track down the problem.

If you are interested in doing this, please describe your present system including router, modem and other network gear that may be relevant. (In earlier threads, you mentioned a backup internet connection using mobile data, as well as a second trunking provider.)

Do you have a static (or de facto static) IP address with NBN? If so, you may be able to configure your trunking provider to send calls directly to your host, without depending on registration. If not, do you know whether the trouble is associated with an IP address change?

If your PBX is not reachable when a call comes in, what happens (call is forwarded to your mobile, provider takes a voicemail, caller hears busy tone or error message, etc.)? What control do you have over this?

Are your trunks pjsip or chan_sip? Have you tried the other as a possible fix? If so, what happened (didn’t help, couldn’t get other driver to work properly)?

8

This is a known problem with Chan-SIP. It was actually one of the drivers for the establishment of PJ-SIP.

Instead of initiating the reload from the inside, you could also look into using a system like Nagios to check and see if the host is registered and, when that fails, initiate a core reload from the monitoring app.

9

Thanks gentlemen
Stewart, I use a SIP trunk for outgoing calls, and PJSIP for incoming, with different user numbers and passwords for each. It was the Outgoing calls that took longer to come back up.

I just ran a test by rebooting the router and the registrations for both were back up in a matter of minutes.

Looking at the log from the other day, I find this:

[2019-05-29 15:30:07] NOTICE[2401] chan_sip.c: Peer ‘10xxxx4’ is now Lagged. (3050ms / 2000ms)
[2019-05-29 15:30:07] NOTICE[2401] chan_sip.c: Peer ‘new siptalk sip’ is now Lagged. (3075ms / 2000ms)
[2019-05-29 15:30:10] SECURITY[2734] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2019-05-29T15:30:10.110+1000”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7f1b4c034c20”,LocalAddress=“IPV4/TCP/0.0.0.0/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/59846”,UsingPassword=“0”,SessionTV=“2019-05-29T15:30:10.110+1000”
[2019-05-29 15:30:21] NOTICE[2401] chan_sip.c: Peer ‘10xxxx4’ is now UNREACHABLE! Last qualify: 3050
[2019-05-29 15:30:21] NOTICE[2401] chan_sip.c: Peer ‘new siptalk sip’ is now UNREACHABLE! Last qualify: 3075
[2019-05-29 15:30:34] SECURITY[2734] res_security_log.c: SecurityEvent=“ChallengeSent”,EventTV="2019-05

and

15:30:34.896+1000",Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7f1b60025e40”,LocalAddress=“IPV4/TCP/0.0.0.0/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/59850”,UsingPassword=“0”,SessionTV=“2019-05-29T15:30:34.896+1000”
[2019-05-29 15:30:35] WARNING[9025][C-0000033b] app_dial.c: Unable to create channel of type ‘SIP’ (2:51 PM 1/06/2019 - Subscriber absent)
[2019-05-29 15:30:39] SECURITY[2734] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV="2019-05-

I’m not sure if more will add any useful info.

Its a pretty straightforward set up: NBN with 50/25 speed, Standard Netgear router, Static external IP Address, no fancy NAT settings or anything like that. Siptalk provides the Sip.
I have discussed with them the idea of the setup that avoids the need for registration, and might re-visit that.

I use SIP for outgoing calls because I had run into problems with PJSIP for outgoing calls in the past, and have never gone back. When I started getting incoming calls from the VOIP provider as well, Chan-SIP didn’t work. So I have PJSIP for that. Sorry I have no more detail about what failed for either of those, it just works the way it is. Mostly…

Dave, thanks for the info and I will look into it at a later date.

I suspect the problem lay with the VOIP provider, I know they did a server reboot in the middle of the day last week, and all these problems happened then as well.

One last thing: Other than lack of elegance, does “core reload” potentially cause problems? Ultimately the problem is that I am frequently not on site and I just need everything to be as automatic as it can possibly be.

Thanks
Peter

10

Though there are of course no guarantees, I’m not aware of any ill effects of “core reload”. It happens whenever you Apply Config, which I’d guess occurs hundreds of times in the life of a typical system. It does do a lot of ‘clanking’; if you have hardware problems such as flaky memory it might cause a crash. And it writes several hundred lines of logs; if you did thousands in a short time you might fill up the hard drive.

Note that pjsip trunks have several settings that by default will cause a temporary outage to result in permanently lost registration, until a reload. Pay particular attention to Max Retries (change it from e.g. 10 to 100000) and also look at Permanent Auth Rejection and the various Retry Interval settings.

I know nothing about Siptalk but took a quick look at their site. Outbound rates seem quite expensive. If they are also unreliable, maybe it’s time to look for another provider. What’s your approximate monthly minutes usage incoming, outgoing to landlines, outgoing to mobiles?

I assume that when your PBX is unavailable for an incoming call, Siptalk takes a voicemail. They have a voicemail to email feature. You could set that up to forward to an address that notifies you “instantly” by SMS or push notification, so you could take corrective action.

11

This works in my test set-up, but in production, it fails. The dialplan runs, and gets as far as sending the command to do “core reload” But then seems to lose connection. Strange because it is installed from the exact same copy of the .iso and the test set-up is just reloaded from the backup of the production. Anyhow, this is what I see.

[2019-06-08 06:34:04] VERBOSE[23065][C-00000500] pbx.c: Executing [301@dial-core-reload:1] NoOp(“PJSIP/702-0000092e”, “”) in new stack
[2019-06-08 06:34:04] VERBOSE[23065][C-00000500] pbx.c: Executing [301@dial-core-reload:2] System(“PJSIP/702-0000092e”, “asterisk -x “core reload””) in new stack
[2019-06-08 06:34:04] VERBOSE[2200] asterisk.c: Remote UNIX connection
[2019-06-08 06:34:04] VERBOSE[23067] asterisk.c: Remote UNIX connection disconnected
[2019-06-08 06:34:04] VERBOSE[23065][C-00000500] pbx.c: Executing [301@dial-core-reload:3] Hangup(“PJSIP/702-0000092e”, “”) in new stack
[2019-06-08 06:34:04] VERBOSE[23065][C-00000500] pbx.c: Spawn extension (dial-core-reload, 301, 3) exited non-zero on ‘PJSIP/702-0000092e’

Is there something in the Advanced settings that might make that happen?

12

I don’t know if this would be a clue. In my test set-up, which runs the reload, the same bit of the log does this:
[2019-06-12 07:57:55] VERBOSE[4165][C-00000000] pbx.c: Executing [301@core-reload-remote:1] NoOp(“PJSIP/708-00000000”, “”) in new stack
[2019-06-12 07:57:55] VERBOSE[4165][C-00000000] pbx.c: Executing [301@core-reload-remote:2] System(“PJSIP/708-00000000”, “asterisk -x “core reload””) in new stack
[2019-06-12 07:57:55] VERBOSE[2172] asterisk.c: Remote UNIX connection
[2019-06-12 07:57:55] ERROR[4168] config_options.c: Unable to load config file ‘acl.conf’
[2019-06-12 07:57:55] WARNING[4168] named_acl.c: Could not reload ACL config
[2019-06-12 07:57:55] NOTICE[4168] cdr.c: CDR simple logging enabled.
[2019-06-12 07:57:55] VERBOSE[4168] cel.c: CEL logging enabled.

And then continues to run the reload.
Any ideas?

13

I seem to have stumbled across a solution.

In the extensions_custom.conf file, instead of asterisk -x “core reload” I used asterisk -x ‘core reload’
ie single quote mark around core reload.
Now it works in my production version.
I have no idea why it works in one and not the other with the double quote marks. They are identical versions.

14

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.