Asterisk CLI Bug?

Dear all,

I’m using Asterisk 1.4 from 3 different host and I’ve always the same problem. The cli work fine for a few command and stop to execute my command randomly !?!
Like it can’t communicate with the pid any more…

I’ve never meet this pb before 1.4. Does anybody has the same pb ?

Thank you, FB.

does it stop working completely or just “lose” commands past a certain point ?

Asterisk is continuing to work perfectly ! Command under cli are not sent to the pid.

how would you know the asterisk is working fine ??? is it executing calls and other processes while you cannot execute a CLI command…???

because yes!!! i’ve seen asterisk 1.4 getting stuck… it keeps on processing already made calls or newer ones to some extend while its just a mere time before i need to stop asterisk manually and then restart it…

let says you have million thread processes and they are all running, but when you issue a “stop now” command, the CLI gets stuck while the few already in process calls stay connected…
might be asterisk first tries to kill all the threads and other dependencies then in the last finish all call sessions, and exits…
this is a usual behavoiur with my server…

n i wld relate your prob with it that some thread at yr end get stuck making CLI useless while the call process is still continued !!!

i hope it was clear and helpful, and please correct if i am wrong … :smile:

Yes, I have seen this too. At CLI> I say ‘stop gracefully’ with no calls in progress or ‘stop now’ and it comes back CLI> and waits for more instructions. I don’t have anything to add to that, my usual response is to stop my ssh connection, start a new one, log back in to asterisk and that seems to get the CLI responding again. It has not happened very frequently and my low volume of calls seems to continue uninterrupted.

well “stop gracefully” give its normal behaviour, because before it shutdown asterisk, it waits untill all calls are hangup by the user not by asterisk itself… sooo this command completetion time may vary…

but “Stop now” case should turn off everything by asterisk, without asking from user to turn off their calls… soo some kind of forceful action… which means the CLI should not get stuck after issuing this command, and the asterisk should shutdown as soon as you issue this command…

one more thing that i didnt understand is how come u issue either of these commands, n when the CLI gets stuck, u close yr ssh connection, open one new and then connect back to asterisk… ??? or you mean you start asterisk again

becuase once you issue any of these commands, the asterisk will shutdown sooner or later and then you have to restart it… which means CLI will definitly start working as well because it will be a newer asterisk…

Well this is precisely what you don’t know, whether * has followed the instruction or not. My box is a test box. I can shut down all calls, nothing going on and stop gracefully normally (always 100% with 1.2) would stop * immediately and return me to the linux prompt. That is why it was noticeable in 1.4. Maybe there are more processes to be concerned about in 1.4 that were not active in 1.2. This would be interesting information.

As far as I know, if I close my connection to the server by closing the Putty window this has no effect on whether * continues to run or not. When I reconnect with putty asterisk is still there for asterisk -r.

Maybe there has been enough time elapsed that * has returned to a normal state. It does not happen very often, which makes it remarkable when it does.

how would you know the asterisk is working fine ??? is it executing calls and other processes while you cannot execute a CLI command…???

-> All pbx function is continuing to work fine.
Call / Transferrt / VoiceMail…

et says you have million thread processes and they are all running, but when you issue a “stop now” command, the CLI gets stuck while the few already in process calls stay connected…

-> In mine case a ps -e | grep asterisk give only one process + safe_asterisk.

To retreive the cli I’m restarting asterisk too with the init script.

FB.