[Asterisk-Users] 1.2.9.1 crashed today

[Steve Totaro]

I am still convinced there is some sort of memory leak caused by either 
heavy use of the manager interface or reloading repeatedly.  I have cut 
back on both and have not noticed any of this funkiness since (48 hrs).

My system never stops processing calls but it slows.  On the CLI, it may 
take five minutes for a command to execute but it does finally execute 
(such as sip show peers or show channels)  And calls to the agents sit 
in queue for a while before being delivered to an agent even thought he 
agent is available.

Thanks,
Steve

Matt wrote:
> We're now back on 1.2.6 and running stable.  Been running for over 17
> hours.  Something is wrong with 1.2.9.1
>
> On 6/21/06, Matt <mhoppes at gmail.com> wrote:
>> I'm now wondering if the changes I made were NOT the cause of my 
>> problem.
>>
>> I was just tweaking some settings (on a virgin 1.2.9.1 (no
>> modifications to source code) asterisk system) and did a few reloads
>> and the system stopped processing queue calls.  Still accepted calls
>> to the IVR, but that was it.  I too am rolling back to 1.2.7 as this
>> is happening too often on our production system.
>>
>> On 6/21/06, Tim C. Lewis <tclewis at oreilly.com> wrote:
>> >
>> > we're also seeing a similar problem with 1.2.9.1 (previously 1.2.7.1,
>> > without this error).  our manager interface is used a fair amount from
>> > FOP, and reloads occur staggered throughout the day on changes (but 
>> not
>> > super often).
>> >
>> > when the problem occurs, we see a lot of agent and queue functions 
>> held up
>> > in "show channels", such as AgentCallbackLogin().  the cli is still
>> > responsive to commands, but all incoming zap channels (2 pri's worth)
>> > become unresponsive except for zap channel 1.  our agents also notice
>> > strangeness with our queues.  outgoing zap calls still work fine (same
>> > pris as we use for incoming), and non-zap calls are still good.
>> > already-connected zap calls are also good, but new incoming zap calls
>> > fail.
>> >
>> > "soft hangup"s on those agent/queue/related-sip-channels don't 
>> respond.
>> > reloading some modules work, but a full "reload" errors on either
>> > app_queue or chan_agent (i forget which), and further reloads of 
>> anything
>> > fail after that, due to the queue/agent module never finishing its 
>> reload.
>> > at this point cli responsiveness to various commands becomes 
>> sporadic --
>> > many no longer work, such as "show channels".
>> >
>> > i didn't think to get a gdb backtrace, blah.
>> >
>> > the eventual "fix" each time is a full asterisk stop/start.
>> > unfortunately, it's happened too often (about 4 times in a week) to
>> > continue gathering data with on our production system, so we've rolled
>> > back from 1.2.9.1, but kept zaptel, asterisk-addons, and wanpipe 
>> [sangoma
>> > card] at the latest versions (they were all upgraded simultaneously).
>> >
>> > if the above info helps any debugging efforts, great.  if not, oh 
>> well.
>> > i'll be seeing what else i can dig up as well (from a test system, 
>> logs,
>> > etc).
>> >
>> > -tcl.
>> >
>> >
>> > On Tue, 20 Jun 2006, Matt wrote:
>> >
>> > > Correct.. still running.. just doesn't respond to anything I do, 
>> and I
>> > > have to kill it with the /etc/rc.d/init.d/asterisk stop script
>> > >
>> > > On 6/20/06, Steve Totaro <stotaro at asteriskhelpdesk.com> wrote:
>> > >>  I guess that was a yes to both my scenarios, reloads and manager
>> > >>  interface.
>> > >>
>> > >>  It is still running just not responsive?
>> > >>
>> > >>  Matt wrote:
>> > >> >  Arg... ok it just crashed again.  Lasted about 7 hours this 
>> time.
>> > >> >
>> > >> >  On 6/20/06, Matt <mhoppes at gmail.com> wrote:
>> > >> > >  I use FOP... I believe that that uses manager fairly 
>> extensively.
>> > >> > >
>> > >> > >  Also... about 2-4 hours prior to the crash I had been 
>> playing around
>> > >> > >  with getting new MOH working.. .and had reload 
>> res_musiconhold several
>> > >> > >  times (5 or 6)
>> > >> > >
>> > >> > > >  Just curious, do you use the manager interface extensively?
>> > >> > > >
>> > >> >> > _______________________________________________
>> > >> > > >  --Bandwidth and Colocation provided by Easynews.com --
>> > >> > > >
>> > >> > > >  Asterisk-Users mailing list
>> > >> > > >  To UNSUBSCRIBE or update options visit:
>> > >> > > >     http://lists.digium.com/mailman/listinfo/asterisk-users
>> > >> > > >
>> > >> > >
>> > >> > _______________________________________________
>> > >> >  --Bandwidth and Colocation provided by Easynews.com --
>> > >> >
>> > >> >  Asterisk-Users mailing list
>> > >> >  To UNSUBSCRIBE or update options visit:
>> > >> >    http://lists.digium.com/mailman/listinfo/asterisk-users
>> > >> >
>> > >>
>> > >>  _______________________________________________
>> > >>  --Bandwidth and Colocation provided by Easynews.com --
>> > >>
>> > >>  Asterisk-Users mailing list
>> > >>  To UNSUBSCRIBE or update options visit:
>> > >>     http://lists.digium.com/mailman/listinfo/asterisk-users
>> > >>
>> > > _______________________________________________
>> > > --Bandwidth and Colocation provided by Easynews.com --
>> > >
>> > > Asterisk-Users mailing list
>> > > To UNSUBSCRIBE or update options visit:
>> > >   http://lists.digium.com/mailman/listinfo/asterisk-users
>> > >
>> > >
>> > _______________________________________________
>> > --Bandwidth and Colocation provided by Easynews.com --
>> >
>> > Asterisk-Users mailing list
>> > To UNSUBSCRIBE or update options visit:
>> >    http://lists.digium.com/mailman/listinfo/asterisk-users
>> >
>>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> Asterisk-Users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>