| Summary: | ASTERISK-18200: CLI output is limited to 24000 bytes, running 'dialplan reload' in verbose mode | ||||
| Reporter: | xerofun (xerofun) | Labels: | |||
| Date Opened: | 2011-07-28 05:14:32 | Date Closed: | |||
| Priority: | Trivial | Regression? | |||
| Status: | Open/New | Components: | Core/Configuration | ||
| Versions: | 1.6.2.19 1.8.5.0 13.18.4 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Linux Debian 6.0.2 (Squeeze), both asterisk versions compiled against standard Debian libraries | Attachments: | ( 0) cli-output-broken-dialplan.txt ( 1) extensions.conf | ||
| Description: | Initially I thought not only the output on the CLI is limited, but also reloading the dialplan cuts off at a certain point. It seems that only the CLI output is limited to 24000 bytes when hitting 'dialplan reload'. So I still think this is a (cosmetic) bug, as I really want to see all the output when running in debug mode i.e. 'asterisk -rvvv'. If there's an error in the dialplan in the part that's cut off, I won't see it. Please use the attached extensions.conf to reproduce this by entering the asterisk shell with 'asterisk -rvvv' and enter 'dialplan reload'. Sometimes it works and outputs the full diaplan, but most times it just cuts off at extension 362 or 363. | ||||
| Comments: | By: xerofun (xerofun) 2011-07-28 05:16:33.587-0500 I was unable to reopen the accidentally closed ASTERISK-18195 ticket, so I cloned it creating 18200. By: Leif Madsen (lmadsen) 2011-09-12 16:12:23.418-0500 This is a pretty low priority issue since it provides no functionality issues. I'd suggest providing a patch, and failing that, seeing if you can convince someone else to provide a patch :) By: Corey Farrell (coreyfarrell) 2015-03-28 14:42:53.941-0500 I've reproduced this issue by running asterisk from two terminals using {{asterisk -cvvv}}, then once fully booted {{asterisk -rvvv}}. I am able to confirm this issue, with the attached dialplan the output of {{dialplan reload}} only reached extension 272. Upon further investigation I found we are getting {{errno == EAGAIN}} from {{fdwrite}}. This is due to {{console\[x].p\[1]}} being set to {{O_NONBLOCK}}. Removing O_NONBLOCK does fix the issue, but I'm concerned this could cause slowdowns when something floods remote consoles. O_NONBLOCK was set in SVN revision 367, which has "Version 0.1.9 from FTP" in the commit log. So it's possible that O_NONBLOCK is unneeded, but difficult to prove. In my opinion this would be a high risk/low reward fix that should not be considered for any released version, if at all. As it is I see this as "accidental flood protection". This issue also does not effect verbose logs configured in logger.conf, only consoles. | ||||