How to supress AMD messages in asterisk CLI and log files?

[okli]

Asterisk 1.2.30.4 if matters- how to stop AMD output in asterisk CLI and log files? These AMD messages keep coming up even with verbose 1, and on production machine makes quite difficult troubleshooting or watching CLI in real time due to the number of extra output.

Any clues?

[williamconley]

1) change your logger.conf file to exclude the "class" of message that these belong to (not necessarily a great idea if you want other messages of the same class to appear, but worth mentioning as it works immediately). You do have to issue "logger rotate" afterwards in the asterisk cli. In the logger.conf file, the line to edit is "console". You CAN add that "class" to another location (other locations are files, which I generally rename to end in ".log") so that you still get the information in question. But remember logging takes up resources, if you are tweaking.

2) modify your source code for AMD and change the messages you DON'T want to "debug" class messages. Then they'll only appear with the rest of the debug messages (ie: when debug is on). Of course, this will require recompiling ... not for the squeemish. definitely a "go" for a true linux person. (Most of my installs are Gentoo ... EVERYTHING is compiled directly on the box)

that's it for me, anyone else?

[okli]

In logger.conf I have
console => notice,warning,error
messages => warning,error

In MESSAGES file there are no signs of AMD output, they appear on CLI only, will chack later on today how exactly they are displayed in console when in agents start work.

So it seems those AMD messages are from class NOTICE, which I'd rather keep in the console.

At the same time, reading app_amd.c and app_amd2.c it appears those messages are for class VERBOSE, with verbosity level at least 3, if I interpret the code correctly:

Code: Select all

ast_verbose(VERBOSE_PREFIX_3 "AMD: ANSWERING MACHINE: iWordsCount:%d\n", iWordsCount );

In a debug file I am temporarily dumping (debug => notice,warning,error,verbose) I see this:

Code: Select all

Oct  4 09:32:47 VERBOSE[10005] logger.c:     -- AMD: Word detected. iWordsCount:1
Oct  4 09:32:48 VERBOSE[10005] logger.c:     -- AMD: Changed state to STATE_IN_SILENCE
Oct  4 09:32:48 VERBOSE[10005] logger.c:     -- AMD: HUMAN: silenceDuration:1000 afterGreetingSilence:1000

Note VERBOSE.

So here is where I am stuck. What am I missing?

Next to try is "set verbose 0" rather than 1, maybe AMD stuff appears even with verbosity level 1, which would be pity as as soon as we need a bit more verbosity at CLI, it will be flooded again...

[okli]

Hmm...
Neither set verbose 0, nor console => warning,error did the trick- CLI is still flooded with AMD messages.

Further reading of source code of a few asterisk applications show lines like:

app_meetme.c :

Code: Select all

....
if (option_verbose > 2)
            ast_verbose(VERBOSE_PREFIX_3 "Created MeetMe conference %d for conference '%s'\n", cnf->zapconf, cnf->confno);
...

whereas no such conditions are present in app_amd.c.

May have to experiment a bit adding such conditions in app_amd.c and recompile asterisk, unless a better ideas come up.

[williamconley]

what class of message is this annoyance of yours, and did you rotate the logger after you changed your logger.conf?

Code: Select all

Asterisk CLI> logger rotate

[okli]

Sorry, been away for a while.

Neither "logger reload", nor "logger rotate" did the trick.

Seems like messing with app_amd.c code and recompiling asterisk is the option for now.

[williamconley]

Cool. How much are you willing to pay?

[okli]

For adding a few lines in app_amd.c and recompiling asterisk?

Or you got another idea?

[williamconley]

Actually, if you're a cheapskate, it would be for deleting a line and recompiling, most likely.

If you're not TOO cheap, it would be for modifying a line (a little research to see if the verbosity level could be raised or if it could b move to debug, would be interesting).

And of course for posting the result on THIS site for "others" to use. Honestly, you should look for it yourself. Lazy bum!

[okli]

The issue is not urgent, just annoying. Moving across continents currently, jetlag is hitting hard as well. No much spare time since I started the topic to pay attention and dig deeper on this issue. At the same time I won't just "leave" the topic if there are posts in it.

The purpose of the thread was if there was a trick which I've missed, something like "asterisk CLI>amd no debug", extra line in amd.conf or something around that line.

If the right direction is to play with app_amd code I would just do it myself as soon as I get a chance- didn't expect, nor wanted, someone to do that for me. And would share any details here, just as usual.

[williamconley]

marvelous. cuz now i'm curious. lol

[okli]

At first glance it may turn out as not a bug, but needed behavior

In most app files in default asterisk 1.2.30.4 directory /apps/ condition for verbosity is used:
like:

Code: Select all

if(option_verbose > 3)
            ast_verbose(VERBOSE_PREFIX_4 "Channel %s was never answered.\n", dchan->name);

app_amd.c coming with asterisk 1.4.21.2 does have those conditions as well:

Code: Select all

if (option_verbose > 2)
                  ast_verbose(VERBOSE_PREFIX_3 "AMD: Word detected. iWordsCount:%d\n", iWordsCount);

Same conditions are used in all versions of app_amd.c I found around, but not in the ones in eflo.net and vicidial.com.

Reading logger.h documentation from 1.4 branch:
http://www.asterisk.org/doxygen/1.4/log ... ource.html

Code: Select all

#define VERBOSE_PREFIX_1 " "
#define VERBOSE_PREFIX_2 "  == "
#define VERBOSE_PREFIX_3 "    -- "
#define VERBOSE_PREFIX_4 "       > "

shows that VERBOSE_PREFIX_N is actually the prefix printed at front of the actual message, NOT the verbosity level.

At the same time Vicidial's VD_amd.agi and VD_amd_post.agi seems to read output of app_amd and decide what to do with the call.

So for now I'd guess the lines about verbosity level were removed on purpose.

[williamconley]

if (option_verbose > 2)
ast_verbose(VERBOSE_PREFIX_3 "AMD: Word detected. iWordsCount:%d\n", iWordsCount);

Is the "word detected" line the one you want to remove?

If so ... would you not change the "if ...>2" to a higher number

Or CHANGE IT TO "option_debug" and "ast_debug" (or whatever the send a debug message is)?

OR simply remove the line entirely (and perhaps the if ... >2 with it, since it would not longer be doing anything?)

[okli]

Is the "word detected" line the one you want to remove?

It's not the only one, the line posted is just one of the many similar ones.

If so ... would you not change the "if ...>2" to a higher number

Because "if(option_verbose > 3) " part is NOT present in app.amd.c in vicidial.com and eflo.net.
You must have missed that:

Same conditions are used in all versions of app_amd.c I found around, but not in the ones in eflo.net and vicidial.com.

And yes, the options are to add that condition "if(option_verbose > 3)" or change output to debug, but I believe it was made like this on purpose, in order VD_amd.agi and VD_amd_post.agi to read output from AMD and decide what to do with the call.

Unless Matt notices this topic and confirm or not what the case is, I'd play in a test install as soon as I can to find out if that's the case.

[williamconley]

the trick is to find the actual one that is displaying (or i guess you could modify all of them at once with a search and replace ... after all, they are just verbose messages, and do not even display if verbose is set to "0" and there is no logging anywhere (logger.conf NOT containing a "verbose" entry)

but more to the point: does AMD still work if "verbose" is set to 0?

if it does ... then this line is not the one being read, it's being sent back by agi instead of being read by a screen and *poof* you can kill it at will. (which i would try anyway just to find out, after all it can always be set back easily ...)

[okli]

Right now as it is, even with verbose 0, those messages are displayed. This has been mentioned already.

Yes, I'd add similar condition "if(option_verbose > 3)" to all messages printed out by app_amd.

I have no quick way to find out whether AMD will work without those messages printed out or not. Have to set a test machine and play a bit.

[williamconley]

sorry, i must have been reading too quickly. i forgot that the verbose 0 didn't work.

and you are saying that even with verbose set to NOT show in logger.conf anywhere ... you still can't get rid of it?

are there any circumstances under which you CAN kill it?

(or did i read too quickly again, long day ...)

[okli]

http://www.vicidial.org/VICIDIALforum/v ... 5737#35737

[williamconley]

So it seems those AMD messages are from class NOTICE, which I'd rather keep in the console.

I guess that would be my point. LOL

Have you TRIED to turn off "notice" and be sure it goes away.

Programmers (web and executable alike) often "decide" that it works/doesn't work, whatever. I seriously prefer (and require from my programmers) an actual TEST. Often one finds out that one's "decision" was in error ... (a client will certainly test it, after all that's why they paid for it ... if the client is the FIRST one to test it, the programmer needs a pay cut).

IE:

I never heard "Yep, I can get rid of it by ..." or "Nope, it just plain will NOT go away, even if i take EVERYTHING out of logger.conf for the console, that sucker is still there ...".

Strangely enough, however, that would be my method of finding where to look for it (to be SURE it will be somewhere in my path while i'm looking). I hate wild geese.

[mflorell]

On a somewhat related note, we have changed the notification verbosity of the waitforsilence app in the code at client request before.

[okli]

@williamconley

AMD messages are from VERBOSE class, no matter what verbosity level is set to. It's been put above in the topic. I really don't feel comfortable doing that- reminding every post what has been already posted

At the same time, reading app_amd.c and app_amd2.c it appears those messages are for class VERBOSE, with verbosity level at least 3, if I interpret the code correctly:

This was not correct as was posted later on:

Reading logger.h documentation from 1.4 branch:
http://www.asterisk.org/doxygen/1.4/log ... ource.html
...
shows that VERBOSE_PREFIX_N is actually the prefix printed at front of the actual message, NOT the verbosity level.

Neither set verbose 0, nor console => warning,error did the trick- CLI is still flooded with AMD messages.

I have modified app_amd2.c and installed a test VMWARE machine- this worked beautifully, AMD works just fine with verbosity level 0-3, when AMD messages are not yet displayed on CLI.

@mflorell

Should I put the modified file in Mantis? Or maybe you want to have a look at it first?

http://www.datafilehost.com/download-5bf507ee.html

As I get it current install instructions of Vicidial are for asterisk 1.4.21.2 and its default app_amd.c, which has AMD messages displayed only with verbosity > 3, so this patch wouldn't be of any use, right?

[mflorell]

You're right, we don't really do any active development for Asterisk 1.2 at this point. But please do upload it on Mantis.

[okli]

Here it is:
http://www.vicidial.org/VICIDIALmantis/view.php?id=239