[Home]

Summary:ASTERISK-05682: #exec does not work in all instances
Reporter:John Todd (jtodd)Labels:
Date Opened:2005-11-23 03:05:06.000-0600Date Closed:2011-06-07 14:10:41
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/Configuration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Using "#exec wget http://www.loligo.com/stamps.html" as a test beacon, I have been able to duplicate unusual behavior with 1.2.0 and #exec.  Sometimes the #exec fires, and sometimes it does not ,and it seems to be based on either debug mode or console attachment.

Yes, I have added these lines to asterisk.conf:

[options]
execincludes=yes    

If I launch asterisk like "asterisk -vvvvvgcd" the #exec fires and the file appears in /etc/asterisk as a result of the wget.  However, if I just run "asterisk" with no console, the file is not fetched, nor does "reload" or "extensions reload" cause it to fire.

Interestingly, using "#exec touch foo" works in debug or console-less modes of launch on the Soekris, but does not work at all on my 2004-11-09 distribution on RH9.  I'm fairly perplexed.

Primary testing with 1.2.0 is on a Soekris 4801.  I'd be running CVS-HEAD, but the @#%(@#%@# CVS servers are down this evening, so I'm stuck with what I've got.
Comments:By: John Todd (jtodd) 2005-11-23 03:06:06.000-0600

Also, my apologies if this is in the wrong place - not quite sure where #exec would fit other than "Dialplan Functions" even though it's not a function in our definition of the word...
By: Olle Johansson (oej) 2005-11-23 09:16:13.000-0600

Mr Todd, it's a "config" issue.

/The Concierge Dept.
By: Olle Johansson (oej) 2005-11-23 09:21:07.000-0600

As I understand it, #exec should not create a file, but take the output of the exec command and embed that as input in the configuration file. So the file should not really be created...

And your HTML file *should* generate an error, since the syntax of that file does not really follow Asterisk configuration file standards.

Having said that, I have to admit that I haven't played around a lot with it.
By: John Todd (jtodd) 2005-11-23 15:30:10.000-0600

So, then perhaps you can explain why it works as *I* expected it to work during some tests, but not during others?  (where "works" = downloads the file "stamps.html" and puts it in /etc/asterisk)

In fact, I'm not so sure I like the description you've given as to how this works and why it shouldn't do what I think it should do.  I modified my command to look like this:

#exec wget -q http://www.loligo.com/stamps.html  

which results in NO standard out result from the command.  Even using your description (which is probably correct) of the way that the #exec syntax was envisioned to work, it should STILL create the file on disk, and include the null result in the configuration file, thus resulting in NO ERROR.  How would it possibly do otherwise?  

Something is still wrong here with the code.


Slightly-off-topic:

My method of #exec is designed for explicit inclusion of config files using #include later on, and is simply a slightly less error-prone way to fetch configs from external sources (since I'm storing the previous results on disk, temporary failures will result in last-file-used.)  In other words:

#exec wget -q http://www.loligo.com/stuff/dynamic-extensions.conf
#include dynamic-extensions.conf
By: twisted (twisted) 2005-11-23 22:32:59.000-0600

jtodd: oej is correct actually, here's the code snippit from line 470 in config.c:

                              /* #exec </path/to/executable>
                                  We create a tmp file, then we #include it, then we delete it. */
                               if (do_exec) {
                                       snprintf(exec_file, sizeof(exec_file), "/var/tmp/exec.%ld.%ld", time(NULL), (long)pthread_self());
                                       snprintf(cmd, sizeof(cmd), "%s > %s 2>&1", cur, exec_file);
                                       ast_safe_system(cmd);
                                       cur = exec_file;
                               } else
                                       exec_file[0] = '\0';
By: Olle Johansson (oej) 2005-11-24 01:07:24.000-0600

So something is wrong when it works as jtodd expects :-)

Jtodd: If you created a shell script that fetched the file to the hard disk with wget and had *no* output on stdout, that would do what you wanted. Nothing would be included because of the #exec
By: John Todd (jtodd) 2005-11-25 18:42:52.000-0600

OK, so let me try what Olle suggests:  :-)

poptart# cd /etc/asterisk
poptart# cat >fetcher
#!/bin/sh
/usr/bin/wget -q http://www.loligo.com/stamps.html
^D
poptart#
poptart# chmod a+x fetcher
poptart#  ls -ls stamps.html
ls: stamps.html: No such file or directory  
poptart# ./fetcher
poptart# ls -lsa stamps.html
  4 -rw-r--r--    1 root     root          424 Nov 26 00:24 stamps.html
poptart# rm stamps.html

Now, I add this line to extensions.conf:

#exec /etc/asterisk/fetcher

and I perform an "extensions reload".  I see this on the console:

poptart*CLI> extensions reload
Nov 26 00:20:10 WARNING[2916]: config.c:525 process_text_line: No '=' (equal sign) in line 1 of /var/tmp/exec.1132964410.245765    

...but look!  No file!

poptart# ls -lsa /etc/asterisk/stamps.html

In fact, that file doesn't exist _anywhere_ on my system.  Therefore, I can only conclude that for some reason the #exec operative is somehow failing to correctly execute the given command.  It's not that the stdout is missing; I don't really care about the stdout.  I don't think the command is executed AT ALL in some instances.  Can you duplicate this?

Note: my CVS-HEAD machines don't produce the WARNING on "extensions reload".
By: John Todd (jtodd) 2005-12-01 20:47:09.000-0600

OK, so this seems to be some specific bug with wget.   For some reason, the way that Asterisk hands it a controlling shell does not seem to be compatible with wget.  I replaced "wget -q" with "curl -s" and things work, though I had to redirect the output appropriately.

If the "fetcher" script looks like this, things work:

#!/bin/sh
/usr/bin/curl -s http://www.loligo.com/stamps.html > /etc/asterisk/stamps.html

This bug should probably be closed now, but I'm wondering what "magic" (or lack thereof) is causing wget to choke when it is executed from Asterisk versus being executed on the command line.