Does externnotify wait for return?

I haven’t started digging through the code yet (as I am not a c programmer myself). I am kind of hoping someone might know this off the top of their head.

Info:

I’ve been using Trixbox 1.2.2 for a few months now as a voicemail platform for a Cisco CallManager 5.0.4. Occasionally * would lock up on me, it has maybe a total of 4 times now. This last time I actually had enough debugging and verbosity on so that I might know what it died doing. The last item I show in my log for asterisk is a debug message from app_voicemail.c calling a script that writes a call file that is used to turn on/off mwi on the phones on Cisco CallManager. (Script is an extremely short/simple shell script).

Symptoms:
Now this is my viewpoint, it seems that * become totally unresponsive and I have to issue a “service asterisk stop” and a “service asterisk start” to get any activity to happen. Nothing more is written to the logfiles when asterisk has “frozen”. If I issue the command “asterisk -r” to get to the command prompt of asterisk I get the following:

[b][root@asterisk1 ~]# asterisk -r
Asterisk 1.2.11 svn rev 40948, Copyright © 1999 - 2006 Digium, Inc. and others.
Created by Mark Spencer markster@digium.com
Asterisk comes with ABSOLUTELY NO WARRANTY; type ‘show warranty’ for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type ‘show license’ for details.

[/b]

Note the fact that I don’t get a prompt. I expected a asterisk1*CLI>.

Ultimate question:
Sorry for being so longwinded. Does the app_voicemail.c when calling the externnotify application expect a return code or anything else? Can a problem in the script being run cause asterisk to lockup?

I’m digging through the code, I’m completely not familiar with c so I may be way off-base here.

After digging through the code a little, it does appear that in app_voicemail.c
run_externnotify calls ast_safe_system and ast_safe_system forks the program and waits on it indefinitely. However without knowing how/if other processes that may have called the run_externnotify are called (are they forked?).

I’m just throwing around ideas here because I’m not quite sure how to proceed. If there were a flaw in the script associated with externnotify and the process never returned would this cause more memory to be used up gradually? Would I see these processes when I run ps? Would I have more context switching?

I guess if it comes down to it, I can rewrite this little shell script in python (something I’m more familiar with) so that I can do my own logging and try to figure out if there is a breakdown somewhere.

It appears I’m having a nice conversation with myself.

Something else I noticed is that the shell script I am using is creating the file directly in the /var/spool/asterisk/outgoing directory. I’m certain that this is a Bad Thing so I’m going to work around it with a rewrite of the script. I guess this raises a new question… what happens if there is an invalid call file in the outgoing directory? Will asterisk ignore it if there is an error reading a call file? I guess I need to check to see if any logging is written before a call file is executed to see if * even got that far.

talking to self continued:

asterisk seems to handle incorrectly written call files gracefully. So I’m going to move on to seeing if I can break the script in a way that it won’t return.

Hi

Just so you are not talking to your self.

I assume you are using a call file to dial a code on the Cisco correct?

It may be worth looking at doing that via the manager interface. as call files can be a pain as, as you say there is no return or error if they fail.

Ian