Trying to debug why a script doesn't run

[dan_ce (D E)]

I’ve got a script that I call from a custom destination. I’m trying to debug why it isn’t being called by the custom destination anymore. I’ve tried turning agi debugging on (because the logs show the script being called, then nothing else at all relating to the script) but that doesn’t seem to show anything helpful related to the script. Any thoughts most welcome!

cheers

[cynjut (Dave Burgess)]

Logs of the failure would come in handy.

[dan_ce (D E)]

Sorry, indeed they would! I linked to them above but didn’t make it clear that’s what I was linking to!
They’re here and below

[2019-09-30 20:48:36] VERBOSE[24346][C-00000063] pbx.c: Executing [dest-3@customdests:2] Gosub("SIP/31-00000034", "domyothercommand,s,1()") in new stack
[2019-09-30 20:48:36] VERBOSE[24346][C-00000063] pbx.c: Executing [s@domyothercommand:1] System("SIP/31-00000034", "/home/asterisk/sendanemail.sh") in new stack
[2019-09-30 20:48:36] VERBOSE[24346][C-00000063] pbx.c: Executing [s@domyothercommand:2] Return("SIP/31-00000034", "") in new stack

[avayax (Johann Zurner)]

So you are saying the script executes fine if you run it directly from command line?

How about adding a dot in front of the directory path in your dial plan to indicate that you are executing a shell script.

[dan_ce (D E)]

I am saying that, yes. I’ll try a dot in front and report back.

[avayax (Johann Zurner)]

Is the script executable by the Asterisk user?

[dan_ce (D E)]

yep both owner and group is asterisk. What’s weird is that this worked before! I tested it thoroughly before implementing it and now it’s silently failing

[dan_ce (D E)]

So now I get

[2019-10-01 15:42:14] VERBOSE[26687][C-000000a5] pbx.c: Executing [dest-3@customdests:1] NoOp("PJSIP/20-000001e8", "Entering Custom Destination domyothercommand") in new stack
[2019-10-01 15:42:14] VERBOSE[26687][C-000000a5] pbx.c: Executing [dest-3@customdests:2] Gosub("PJSIP/20-000001e8", "domyothercommand,s,1()") in new stack
[2019-10-01 15:42:14] VERBOSE[26687][C-000000a5] pbx.c: Executing [s@domyothercommand:1] System("PJSIP/20-000001e8", "./home/asterisk/sendanemail.sh") in new stack
[2019-10-01 15:42:14] WARNING[26687][C-000000a5] app_system.c: Unable to execute './home/asterisk/sendanemail.sh'

This time the script doesn’t proceed to play the announcement, so this time at least it’s aware it’s failed on some level.

[dan_ce (D E)]

There seem to be quite a few threads about scripts silently not working, so I tried a tip from one of them, to see if it would help me. It hasn’t. Just posting here for info.

[domyothercommand]
exten => s,1,TrySystem(/home/asterisk/sendanemail.sh > /dev/null 2>&1 &)
exten => s,n,Return

[avayax (Johann Zurner)]

Do you have anything in the mail logs?

[avayax (Johann Zurner)]

If it doesn’t work you can use system and the mail command to send an email.

[dan_ce (D E)]

hi, I’d be very interested in this, as I’ve again just called the script directly from the console using bash and it instantly worked. I’ll see if I can find out how to send an email from asterisk. Thanks!

[lgaetz (Lorne Gaetz)]

Multiple custom extensions for sending emails when called

Change the dialplan to: [send-email] exten => _.,1,NoOp(Entering user defined context [send-email] in extensions_custom.conf) exten => _.,n,set(emailaddresss=${STRREPLACE(EXTEN,:,@)}) exten => _.,n,System(echo 'Call from ${CALLERID(name)} at ${CALLERID(number)}' | mail -s 'SUBJECT' '${emailaddresss}') exten => _.,n,hangup() Then the custom dial string becomes: local/email:domain.com@send-email you replace the @ symbol in the email address with a :

[cynjut (Dave Burgess)]

@dan_ce

TrySystem(/home/asterisk/sendanemail.sh > /dev/null 2>&1 &)

Try this instead:

TrySystem(. /home/asterisk/sendanemail.sh > /dev/null 2>&1 &)

The ‘dot space’ means “feed me to the default shell”.

[PitzKey (Itzik)]

Did you try putting a noop or an answer as the s,1? I’ve seen that without free of these it can sometimes cause issues.

[dan_ce (D E)]

@cynjut

Try this instead:

TrySystem(. /home/asterisk/sendanemail.sh > /dev/null 2>&1 &)

The ‘dot space’ means “feed me to the default shell”.

Thank you - that did the trick - bizarrely that dot space wasn’t needed a few days ago, which led me to believe all was working reliably - cue red face when certain thing didn’t happen when they should have! Anyway working again now, for now! Shouldn’t the previous none dotted solution have triggered some kind of warning or error?
Thank you!