| Summary: | ASTERISK-10533: CLI: No more connections allowed | ||
| Reporter: | pkempgen (pkempgen) | Labels: | |
| Date Opened: | 2007-10-15 12:58:17 | Date Closed: | 2007-10-15 14:24:49 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | A strange thing happened: Asterisk does not allow any more connections to the CLI, but it's still running. ---cut--- asterisk -vr Asterisk 1.4.13, Copyright (C) 1999 - 2007 Digium, Inc. and others. Created by Mark Spencer <markster@digium.com> Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details. This is free software, with components licensed under the GNU General Public License version 2 and other licenses; you are welcome to redistribute it under certain conditions. Type 'core show license' for details. ========================================================================= Connected to Asterisk <Version Unknown> currently running on No more connections allowed (pid = -1) No more connections allowed *CLI> Disconnected from Asterisk server Executing last minute cleanups ---cut--- ****** STEPS TO REPRODUCE ****** Unable to reproduce, since this is probably caused by other bugs which I cannot reproduce. ****** ADDITIONAL INFORMATION ****** As I can tell from the source code it allows a maximum of 128 connections. Here's what I do with a cron job every minute asterisk -rx 'logger reload' and asterisk -rx 'queue show XXX' for every queue (5). Didn't cause any problems so far. btw: `ps ax -Lf | wc -l` outputs 727 which is quite a few threads. I would not consider the limitation of simultaneous connections to the CLI a bug, so the *real* bug seems to be hanging CLI connections or CLI commands. While this should not happen in the first place, Asterisk could maybe drop all those zombie connections after a while (if there is a way to tell that they are "dead"). SLES 10 Linux asterisk2 2.6.16.21-0.8-bigsmp #1 SMP Mon Jul 3 18:25:39 UTC 2006 i686 i686 i386 GNU/Linux | ||
| Comments: | By: James Golovich (jamesgolovich) 2007-10-15 13:09:01 While I can't be sure, I suspect the problem your having was resolved recently by fixing the way the -rx processing works. This was just put into the 1.4 SVN branch a few days ago, so it isn't in any official release but you could try to update to that branch. Is this a pretty active box? If you use the -rx arguments with asterisk and theres tons of console messages its possible for the remote console not to exit until it thinks its run out of data to read. By: pkempgen (pkempgen) 2007-10-15 14:13:02 Are you referring to the issues people had with their -rx commands being intermixed with verbose messages? We'll discuss if upgrading to the current 1.4 branch is an option. Even if we did, we'd not be able to tell if it cured the problem, as we're unable to reproduce this with the 1.4.13 tag. The box isn't really busy. There are spikes of about 20 to 30 simultaneous calls but 10 calls are more common. No transcoding involved. With a dual-core Xeon @ 2 GHz the machine should be equipped to handle that. Right now there are probably no more than 5 calls because we're outside business hours. So the consoles should have plenty of time to finish reading any data. By: Jason Parker (jparker) 2007-10-15 14:20:31 I suggest we close this bug, and if pkempgen is able to reproduce (even if it only happens once) on the latest svn branch 1.4, we can definitely reopen it. Would that be acceptable? By: pkempgen (pkempgen) 2007-10-15 14:22:27 Sure. By: Jason Parker (jparker) 2007-10-15 14:24:48 Close, per previous note. Again, if you see this happen again after updating to the latest svn, please do reopen this issue. By: Paul Thompson (tcom) 2011-11-11 12:05:45.902-0600 Asterisk 1.4.30, palasonto build, rock stable for over 12 months has just gone belly up at 3.40am this morning with the system alerting me that the ISDN PRI service was down. Upon investigation some 30 minutes later with the alarm script still screaming, discovered could not login to the CLI. So whats changed... only one thing. The virtual fax feature in Elastix GUI was enabled a few days back. Whilst its worked without incident, searching the logs indicates an issue with IAX2 registration. I wish I had looked further into the PS like pkempgen, albeit just wanted it back online. Restored service with a asterisk stop and start service. | ||