[Home]

Summary:ASTERISK-01104: asterisk -xr not showing full response.
Reporter:zoa (zoa)Labels:
Date Opened:2004-02-26 05:55:04.000-0600Date Closed:2004-09-25 02:11:25
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bug1110-timeout_exit.diff.txt
Description:if you do an asterisk -xr "iax2 show channels" you will only get 1 or 2 lines of output.

However if you do asterisk -xr "show channels" it does show you all the channels.

Comments:By: zoa (zoa) 2004-02-26 05:56:32.000-0600

julius:/# asterisk -rx "iax2 show channels"
Peer             Username    ID (Lo/Rem)  Seq (Tx/Rx)  Lag      Jitter  Format
julius:/#

(at the moment of doing this, there were 20 iax2 calls, that show up fine with asterisk -r, iax2 show channels)
By: zoa (zoa) 2004-02-26 06:07:06.000-0600

looks like i'm wrong, sometimes when i do show channels it also returns an empty. (about 1 time out of 20, probably depending on the amount of calls, the more verbose messages are being generated, the more chance you get of bad output.)
By: zoa (zoa) 2004-02-26 06:10:55.000-0600

doing a verbose set 0 doesnt help, it has to be something else.

(A while ago i noticed similar behaviour when using the perl viewer.pl to see some ACD statistics, i tried different approaches back then, manager interface, telnet connection, always had the same problem.).
By: zoa (zoa) 2004-02-26 07:44:28.000-0600

the iax2 show channels only reveals an occasional registration message.

julius:/# asterisk -rpx "iax2 show channels"
Peer             Username    ID (Lo/Rem)  Seq (Tx/Rx)  Lag      Jitter  Format
x.x.x.x    (None)      00006/00000  00001/00000  00000ms  0000ms  UNKN
julius:/# asterisk -rpx "iax2 show channels"
Peer             Username    ID (Lo/Rem)  Seq (Tx/Rx)  Lag      Jitter  Format
By: damin (damin) 2004-02-26 08:39:06.000-0600

I get the same thing when using;

watch -n 5 "asterisk -rx 'zap show channels'"

About 50% of the time I get only the header output and no data. I am not running SMP. This happens on Asterisk 0.7.2 and 1.0_stable for me.
By: damin (damin) 2004-02-26 08:44:01.000-0600

Correction. 1.0_stable seems to NOT have the issue. As a test, I tried issuing a;
watch -n 1 "asterisk -rx show modules"

On 1.0_stable the output remains consistent. On 0.7.2 after a couple of runs through the loop, the output goes away and is only displayed sporadically.
By: powerkill (powerkill) 2004-02-26 09:14:38.000-0600

on mine xr don't work but rx does i use 0.7.2
[root@sip root]# asterisk -xr "iax2 show channels"
Asterisk already running on /var/run/asterisk.ctl.  Use 'asterisk -r' to connect.
[root@sip root]# asterisk -rx "iax2 show channels"
Peer             Username    ID (Lo/Rem)  Seq (Tx/Rx)  Lag      Jitter  Format
0 active IAX channel(s)
   -- Remote UNIX connection
By: zoa (zoa) 2004-02-26 09:17:59.000-0600

hmmz, i'm also using asterisk 1.0_stable i thought.
By: Brian West (bkw918) 2004-02-26 15:01:11.000-0600

bug 183 take a look at that.
By: zoa (zoa) 2004-02-26 15:12:15.000-0600

http://bugs.digium.com/bug_view_page.php?bug_id=000183

Well if that bug is fixed, but this one doesnt :)

Last time i checked i had the same problem with the manager and i was hoping that this asterisk -rx thingie would be a workaround for me :(
By: khb (khb) 2004-04-16 18:55:23

This is still a major problem with the manager interface.  It really makes the manager interface rather useless, unless the manager client output is connected to a tty--as when running  'asterisk -rc'-- it appears, otherwise the buffers seem to overflow.
To me
asterisk -rx "show dialplan"
is the most notorious. It's virtually impossible to get the full dialplan into a text file this way.
By: chrisorme (chrisorme) 2004-04-17 09:03:55

I can also confirm this bug and have noticed it in CVS 15/4.
asterisk -rx "iax2 show peers" and asterisk -rx "sip show peers" when executing these commands multiple times from the command line for the first few times it doesn't work, then it'll work and often continue working.  I'm using safe_asterisk (to a console) to run asterisk.
I guess if running something like this from a script you just look out for it being blank below the first line of output and if so run it again until you get a result with a maximum retries to give up after, or wait and then retry.  Oh, it's a hack and it'd be nice to get it fixed properly but hey.  There's ASTERISK-1209 too

edited on: 04-17-04 08:00
By: Olle Johansson (oej) 2004-04-17 12:01:30

Move bug 1216 onto this bug - it was a duplicate.

The problem is still there. I can confirm it on FreeBSD.
By: Olle Johansson (oej) 2004-04-17 12:02:35

Changing severity to "minor" since it's a bug that needs a fix. Any coders out there that can
* Track it to some part of the source code
* Suggest a fix
By: Brian West (bkw918) 2004-04-18 01:27:20

I just tested this... It seems to be giving the full results ... can you test and confirm this if its not the case please post and the bug will go into feedback and we can look into it more.

bkw
By: Olle Johansson (oej) 2004-04-21 15:36:34

This is still an open bug on both FreeBSD and Linux platforms.
By: bleckey (bleckey) 2004-04-21 18:06:47

I'm looking into this at the moment.  It seems to be tied to how we use ast_el_read_char to do the execution of one command.  That function exits if it sees that either of the last two chars of the returned buffer (which can be 512 at most) are '\n'.  

I suspect that it's pure luck as to whether any command will happen to put a \n in either of those places before its completed execution.

I've seen some commands drop out after one line of output. Other times I've got a few screens worth of command ('show dialplan' on a huge IVR system is a good test for me - I can guarantee that will never give me the entire output)..

I think the problem is we need a proper way of deciding that the command output is finished.  No solution yet, but I thought I'd put this up in case it helps give someone else more insight.

One thought I had was to have ast_el_read_char not exit on the '\n' if we have option_exec set, but instead continue.  The exit condition would then (for example) be the initial select timing out.  I don't know if that's portable, or even sensible yet.  Another possibility might be a distinct 'end of command' character or set of characters which we can scan for.  Neither of these solutions seem 'neat' to me.
By: zoa (zoa) 2004-04-23 05:02:53

another thing to try: asterisk -rx "iax2 show channels" never returns the line that says how many channels there are on my system.
By: twisted (twisted) 2004-05-03 00:38:53

I can confirm that iax2 show channels sometimes flakes out as you mentioned above.. it's very inconsistant.....
By: sbingner (sbingner) 2004-05-09 03:46:38

This seems to happen because the command ends up returning success and the client connection disconnects before it finishes reading out everything from it's fd and printing to screen...  now I just need to figure out how to fix that ;)

This happens on "show channels" also, dosn't seem to be isolated to any command... it's just how the remote client works
By: sbingner (sbingner) 2004-05-09 04:39:27

This is the only thing I can think of to fix it, it adds an option -t timeout so you can have * wait timeout miliseconds to exit... the best way to really fix this is to have commands executed return some sort of "command completed" to the client, but that will be a MUCH larger patch ;)
By: twisted (twisted) 2004-06-16 23:33:40

Is this still an issue?  Need some response asap.
By: James Golovich (jamesgolovich) 2004-06-16 23:53:18

This is on my list of things to do.  I had started on it before but ran out of freetime.  I should have some time to take care of it this one soon
By: mustdie (mustdie) 2004-06-24 12:03:10

CVS HEAD as of 06/23/04 still have manager API issue (See bug 1906). I've just tried CVS of 06/24/04 and problem with management interface was gone. Any feedback on this ?
By: mustdie (mustdie) 2004-06-29 00:52:32

Problem is still here. I can't use management interface with partial response. This is very important for me.
By: Rob Gagnon (rgagnon) 2004-07-03 12:07:32

same as ASTERISK-1931967 and ASTERISK-1400183 ???

Need to combine these into one bug
By: twisted (twisted) 2004-07-03 21:00:58

183 is already closed, and I just closed 1967.  People, let's make sure we search the bugtracker for existing issues that are the same before posting new bugs.
By: Olle Johansson (oej) 2004-07-16 11:21:39

A gentle reminder from housekeeping :-)

/O
By: damin (damin) 2004-07-18 00:16:45

This thing is pissing me off and I want to do something about it, but I've spent the last 30 minutes trying to figure out where the hell I should look. It appears, from the comments, that this bug could be corrected by simply monitoring the file descriptor, but I can't really make hide nor hair of it. Perhaps I should stop drinking beer at this point.
By: sbingner (sbingner) 2004-07-18 05:55:05

There's no way to know if you recieved all data from server yet or not, it's that it's talking over a socket and there's no "end of command" marker from *

Somebody was working on changing the protocol the remote client uses to talk to server, but until then the only way to work around it is with the timeout hack that I posted (I don't know if it still applies but it's simple)
By: Mark Spencer (markster) 2004-08-07 10:36:47

Fixed (more or less) in CVS