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:32Date Closed:
Versions: 13.18.4 Frequency of
is a clone ofASTERISK-18195 CLI output is limited to 24000 bytes, running 'dialplan reload' in verbose mode
Environment:Linux Debian 6.0.2 (Squeeze), both asterisk versions compiled against standard Debian librariesAttachments:( 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.