[Home]

Summary:ASTERISK-10410: executing CLI command from command line have bad verbosity
Reporter:Atis Lezdins (atis)Labels:
Date Opened:2007-09-28 13:42:16Date Closed:2007-10-15 07:47:06
Priority:MinorRegression?No
Status:Closed/CompleteComponents:General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk_consolemute_1.4.patch
( 1) asterisk-consolemute.diff.txt
( 2) console_unmute_on_reconnect.patch
( 3) log-mute.diff
Description:I have asterisk running with -vvvd. When i execute command from command line with "-rx" i get "Verbosity is at least 3" all the times, and sometimes i get output of CLI for some period (larger when asterisk is under load).

I would generally expect the "-rx" to have executed with verbosity 0 and debug 0. If i would want to add some verbosity i would do "-v" and "-d" as much as i need.

There is option "-m" that is supposed to mute CLI output, but it doesn't seems to work.



****** ADDITIONAL INFORMATION ******

Here's sample output:

[atis@asterisk2 tmp]$ asterisk -m -r -x "core show version"
Asterisk 1.4.10 built by root @ asterisk2 on a x86_64 running Linux on 2007-09-12 09:26:39 UTC
Verbosity is at least 3
[atis@asterisk2 tmp]$ asterisk -m -r -x "core show version"
   -- Remote UNIX connection
Asterisk 1.4.10 built by root @ asterisk2 on a x86_64 running Linux on 2007-09-12 09:26:39 UTC
Verbosity is at least 3
[atis@asterisk2 tmp]$ asterisk -m -r -x "core show version"
Asterisk 1.4.10 built by root @ asterisk2 on a x86_64 running Linux on 2007-09-12 09:26:39 UTC
Verbosity is at least 3
   -- Executing [0295@default-external:4] Macro("SIP/69.80.215.6-c804c920", "init_vars") in new stack
   -- Executing [s@macro-init_vars:1] NoOp("SIP/69.80.215.6-c804c920", "-(B)------------------------------------- macro init_vars -----------") in new stack
   -- Executing [s@macro-init_vars:2] Set("SIP/69.80.215.6-c804c920", "__TRANSFER_CONTEXT="transfer"") in new stack
   -- Executing [s@macro-init_vars:3] GotoIf("SIP/69.80.215.6-c804c920", "1?4:7") in new stack
   -- Goto (macro-init_vars,s,4)
   -- Executing [s@macro-init_vars:4] Set("SIP/69.80.215.6-c804c920", "__call_id=1191005766.1666") in new stack
   -- Executing [s@macro-init_vars:5] NoOp("SIP/69.80.215.6-c804c920", "Initializing call_id to 1191005766.1666") in new stack
   -- Executing [s@macro-init_vars:6] Goto("SIP/69.80.215.6-c804c920", "8") in new stack
   -- Goto (macro-init_vars,s,8)
   -- Executing [s@macro-init_vars:8] NoOp("SIP/69.80.215.6-c804c920", "Finish if-init_vars-21") in new stack
   -- Executing [s@macro-init_vars:9] GotoIf("SIP/69.80.215.6-c804c920", "1?10:11") in new stack
   -- Goto (macro-init_vars,s,10)
   -- Executing [s@macro-init_vars:10] Set("SIP/69.80.215.6-c804c920", "call_num=") in new stack
   -- Executing [s@macro-init_vars:11] NoOp("SIP/69.80.215.6-c804c920", "Finish if-init_vars-22") in new stack
   -- Executing [s@macro-init_vars:12] GotoIf("SIP/69.80.215.6-c804c920", "1?13:14") in new stack
   -- Goto (macro-init_vars,s,13)
   -- Executing [s@macro-init_vars:13] Set("SIP/69.80.215.6-c804c920", "call_num=0") in new stack
   -- Executing [s@macro-init_vars:14] NoOp("SIP/69.80.215.6-c804c920", "Finish if-init_vars-23") in new stack
   -- Executing [s@macro-init_vars:15] GotoIf("SIP/69.80.215.6-c804c920", "1?16:22") in new stack
   -- Goto (macro-init_vars,s,16)
   -- Executing [s@macro-init_vars:16] Set("SIP/69.80.215.6-c804c920", "call_num=1") in new stack
   -- Executing [s@macro-init_vars:17] Set("SIP/69.80.215.6-c804c920", "DB(call_globals/1191005766.1666/call_num)=1") in new stack
[atis@asterisk2 tmp]$                                                                                                                      
Comments:By: Jason Parker (jparker) 2007-10-02 12:35:52

I looked at this for about 2 hours yesterday, trying to fix the problem reported here, but I realized that it was actually working as intended.

The 'm' option isn't supposed to be used from remote consoles - it is to be used when you start asterisk.

If you start asterisk with -m, any remote consoles that connect will be muted.


As for not turning off the verbosity when connecting without any v's - that is also intended behavior.
By: Atis Lezdins (atis) 2007-10-03 03:55:34

I agree, that m option isn't best suited for turning off verbosity on remote consoles, however i don't agree with connecting remotely without v's.

When connecting remotely with "-r -x" - all i want is output of command i'm executing. I'm in doubt that anybody would want anything else.

Ok, actually it's no problem that i get some strings like "Verbosity is 3", but the problem is - that sometimes after command result i got CLI output for long period of time (up to several minutes under heavy load). As i'm using "asterisk -r -x" in scripts that monitors asterisk status and get's some info - it sometimes causes script to just hang waiting for all the output from asterisk.
By: Atis Lezdins (atis) 2007-10-03 04:41:08

Maybe we can discuss this in mailinglist? If it's really intended (but not expected) behavior, this could be marked as feature for 1.6
By: James Golovich (jamesgolovich) 2007-10-04 02:42:26

I've got this pretty much solved, but I'm curious what the preferred action of -m is.  Like qwell said if you start up the main console with -m then all of the new remote consoles start up muted.

If you start up a remote console with -m, it looks like its supposed to print an error message saying that its muted but it really tries to send that message to the other side.

My opinion of how this should work would be to get rid of the -m usage from the main console (unless it gets made to actually mute the main console) and make it so that if a remote console is called with -m with will mute its output.

The patched I attached does this.  If we want to keep the existing odd behavior, then all the muting commands will have to be extended so we can explicitly set muting on/off rather than just toggle back and forth.
By: Atis Lezdins (atis) 2007-10-04 06:37:16

James, thanks. I backported patch to 1.4 branch.

It seems to not giving any other output than the command, when executing "asterisk -rmx ". I'm just a bit worried that logger might miss something from other threads, but testing didn't showed anything like that. A little disadvantage is that logger doesn't get anything from command executed trough muted console, but i suppose that it's ok. If each console would have different verbosity - there wouldn't be problem like this.

Anyway - i will use this on my production, and i hope it will make to SVN. Thanks again.
By: James Golovich (jamesgolovich) 2007-10-04 10:58:07

What do you mean by "A little disadvantage is that logger doesn't get anything from command executed trough muted console, but i suppose that it's ok." ?

Also you don't need to use -m if -x is used, although it won't do anything out of the ordinary if you do it.
By: Atis Lezdins (atis) 2007-10-04 11:17:35

You're right. And my sentence about hiding is wrong. I did some more testing, and i still see debug messages of "-rx" in log, but nothing extra is returned.

However, there's a little bug with your patch - newly created consoles are starting muted (and doesn't display anything about that).
By: James Golovich (jamesgolovich) 2007-10-04 11:29:27

I wish the bug was in my patch, then it would be easy to be fixed.  It only seems to happen sometimes.  Whats happening is the "logger mute silent" command is getting missed by the main thread.  I suspect a signal is hitting the process at the same time the read is going on and its getting passed up.

I'll look into the solution to that, but I fear it won't be a trivial issue to fix
By: Atis Lezdins (atis) 2007-10-04 11:42:59

Strange, for me problem was every time. However, adding

ast_log(LOG_DEBUG, "CLI command: %s\n",s);

within ast_cli_command() helped, and now my consoles start unmuted. Probably you're right about bad timig.
By: Jason Parker (jparker) 2007-10-04 12:10:28

I have an unfinished patch I was working on (we just moved, so kinda busy right this second) while looking at this initially..  I'll post it in a second.

Hopefully it'll show part of my thought process.
By: James Golovich (jamesgolovich) 2007-10-04 12:42:52

I was wrong about a signal hitting it and causing the command to be missed.  The problem is that the read is pulling in multiple lines, since its reading whatever is available.
By: James Golovich (jamesgolovich) 2007-10-04 17:06:21

Atis,

You can also apply the patch from bug ASTERISK-10448 which will make asterisk execute execute all the commands it receives in a read, so that will resolve the issue you were seeing where it was defaulting to muted.
By: Digium Subversion (svnbot) 2007-10-13 00:27:32

Repository: asterisk
Revision: 85533

U   branches/1.4/include/asterisk/logger.h
U   branches/1.4/main/asterisk.c
U   branches/1.4/main/cli.c

------------------------------------------------------------------------
r85533 | russell | 2007-10-13 00:27:31 -0500 (Sat, 13 Oct 2007) | 12 lines

Fix an issue with console verbosity when running asterisk -rx to execute a command
and retrieve its output.  The issue was that there was no way for the main Asterisk
process to know that the remote console was connecting in the -rx mode.  The way that
James has fixed this is to have all remote consoles muted by default.  Then, regular
remote consoles automatically execute a CLI command to unmute themselves when they
first start up.

(closes issue ASTERISK-10410)
Reported by: atis
Patches:
     asterisk-consolemute.diff.txt uploaded by jamesgolovich (license 176)

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-10-13 00:32:41

Repository: asterisk
Revision: 85534

_U  trunk/
U   trunk/include/asterisk/logger.h
U   trunk/main/asterisk.c
U   trunk/main/cli.c

------------------------------------------------------------------------
r85534 | russell | 2007-10-13 00:32:40 -0500 (Sat, 13 Oct 2007) | 20 lines

Merged revisions 85533 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r85533 | russell | 2007-10-13 01:48:10 -0400 (Sat, 13 Oct 2007) | 12 lines

Fix an issue with console verbosity when running asterisk -rx to execute a command
and retrieve its output.  The issue was that there was no way for the main Asterisk
process to know that the remote console was connecting in the -rx mode.  The way that
James has fixed this is to have all remote consoles muted by default.  Then, regular
remote consoles automatically execute a CLI command to unmute themselves when they
first start up.

(closes issue ASTERISK-10410)
Reported by: atis
Patches:
     asterisk-consolemute.diff.txt uploaded by jamesgolovich (license 176)

........

------------------------------------------------------------------------
By: Atis Lezdins (atis) 2007-10-15 05:53:32

A little bug found regarding to this.

On reconnect (-R) console stays muted.
I added "logger mute silent" on reconnect part - see patch. This works, but i'm not definitely sure that it's the best place.
By: Digium Subversion (svnbot) 2007-10-15 07:45:03

Repository: asterisk
Revision: 85545

U   branches/1.4/main/asterisk.c

------------------------------------------------------------------------
r85545 | russell | 2007-10-15 07:45:03 -0500 (Mon, 15 Oct 2007) | 7 lines

Make sure remote consoles unmute themselves again after reconnecting.

(closes issue ASTERISK-10410)
Reported by: atis
Patches:
     console_unmute_on_reconnect.patch uploaded by atis (license 242)

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-10-15 07:47:06

Repository: asterisk
Revision: 85546

_U  trunk/
U   trunk/main/asterisk.c

------------------------------------------------------------------------
r85546 | russell | 2007-10-15 07:47:06 -0500 (Mon, 15 Oct 2007) | 15 lines

Merged revisions 85545 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r85545 | russell | 2007-10-15 08:05:45 -0500 (Mon, 15 Oct 2007) | 7 lines

Make sure remote consoles unmute themselves again after reconnecting.

(closes issue ASTERISK-10410)
Reported by: atis
Patches:
     console_unmute_on_reconnect.patch uploaded by atis (license 242)

........

------------------------------------------------------------------------