ArgusWriteOutSocket(0xd40bb1e0) max queue exceeded 500001

Fri Aug 23 13:21:40 EDT 2013

Sorry for the delayed response (I thought I had responded...my bad).
To run radium in the foreground under gdb(), on a remote system,
log off and then come back and get back to radium, use screen().

screen() is not hard to use, so if its on your system, run your radium
under gdb(), without daemon mode, in a screen window.  You can go
away and come back anytime to see how its doing.  Once it dies,
you'll be where you want to be, so to speak.

So with respect to zlib, its whether the ./configure program finds the
library.  in your ./config.log you'll find the results of the tests for
where is zlib.  More than likely, its not finding either of these libraries.

The latest clients should have the --without-examples directive.  Do
a " ./configure --help " to see if its there.

All clients need the zlib, in order to process ARGUS_EVENTS, which
can be compressed.  You may need to put in some links in /usr/lib, or
/usr/local/lib so programs can find them if they are installed in funky
places.  

Carter 

On Aug 13, 2013, at 10:52 PM, Craig Merchant <cmerchant at responsys.com> wrote:

> I'm running the version you posted to qosient.com/argus/dev on July 22nd.  I see from one of our messages that you added a --without-examples option, but that email was from the 23rd.  Did you post that latest build yet?  It says the flag is unknown when I tried compiling the latest version a couple minutes ago.
> 
> You said in a previous message that I was missing the zlib compression library.  I find these two packages on my system:
> 
> zlib-1.2.3-27.el6.x86_64
> zlib-1.2.3-27.el6.i686
> 
> Do I need something else?  If I don't remove the "examples" directory, make throws the following:
> 
> ./raclient.c: In function âArgusClientInitâ:
> ./raclient.c:846: warning: implicit declaration of function âwaitpidâ
> ./raclient.c: In function âRaProcessEventRecordâ:
> ./raclient.c:1717: warning: implicit declaration of function âuncompressâ
> ./raclient.c:1717: error: âBytefâ undeclared (first use in this function)
> ./raclient.c:1717: error: (Each undeclared identifier is reported only once
> ./raclient.c:1717: error: for each function it appears in.)
> ./raclient.c:1717: error: expected expression before â)â token
> ./raclient.c:1710: warning: unused variable âlenâ
> 
> I'm not sure whether it's the ratop or ramysql version of raclient.c that's causing the problem, but removing those two directories solves the make problem.
> 
> Since I'm not a developer, I've never used gdb before.  From the tutorials I've found, it looks pretty straightforward.  Since radium usually runs for around 24 hours before it crashes and SSH sessions time out after 5 minutes, is it possible to run gdb in the background and save a log file somewhere?  I haven't found instructions on how to do that.
> 
> Thanks!
> 
> Craig
> 
> 
> -----Original Message-----
> From: Carter Bullard [mailto:carter at qosient.com] 
> Sent: Monday, August 12, 2013 2:09 PM
> To: Craig Merchant
> Cc: John Gerth; Argus (argus-info at lists.andrew.cmu.edu)
> Subject: Re: [ARGUS] ArgusWriteOutSocket(0xd40bb1e0) max queue exceeded 500001
> 
> Hey Craig,
> radium should not be having problems when one of its output queues
> gets big.  It should close the connection and toss all the records.
> 
> If the argus data reader can't keep up, then radium should not keep
> trying to send.
> 
> You are currently the only site that is reporting radium crashing
> problems.  Make sure that you are running the latest version.
> If radium is crashing, then there should be a core file somewhere
> that we can look at.  When you have repeated problems with a program,
> you should run it under gdb() in order to catch when it faults.
> 
> Then we can fix it.
> 
> Carter
> 
> 
> 
> On Aug 12, 2013, at 3:56 PM, Craig Merchant <cmerchant at responsys.com> wrote:
> 
>> John,
>> 
>> In your experience, does a half-million queues messages cause radium to crash or did the radium crash cause the queued up messages?  What does the queue represent?  Is it incoming flows that radium is waiting to process or are they flows that are waiting to be sent to other argus clients like rastream?
>> 
>> Thanks for your prompt reply!
>> 
>> Craig
>> 
>> -----Original Message-----
>> From: John Gerth [mailto:gerth at graphics.stanford.edu] 
>> Sent: Monday, August 12, 2013 12:17 PM
>> To: Craig Merchant
>> Cc: Argus (argus-info at lists.andrew.cmu.edu)
>> Subject: Re: [ARGUS] ArgusWriteOutSocket(0xd40bb1e0) max queue exceeded 500001
>> 
>> It's been my experience that the max queue exceeded message is indicative of a problem that won't be fixed by upping the limit (can't remember if it's possible but so much of argus is configurable that it may well be).
>> 
>> What the message is saying is that there are a  half-million queued messages.
>> Not surprising if radium actually died.
>> 
>> The "dead but subsys locked" message is just a result of the abnormal termination since radium couldn't or didn't remove the lock file on its way down.
>> 
>> John Gerth      gerth at graphics.stanford.edu  Gates 378   (650) 725-3273 fax 725-6949
>> 
>> On 8/12/2013 12:06 PM, Craig Merchant wrote:
>>> Hey, Carter...
>>> 
>>> 
>>> 
>>> I'm still having some issues with radium crashing.  I get that "max 
>>> queue exceeded" message and then if I check radium's status, it says:  "radium dead but subsys locked".
>>> 
>>> 
>>> 
>>> Is the max queue size something that can be adjusted?
>>> 
>>> 
>>> 
>>> Thx.
>>> 
>>> 
>>> 
>>> Craig
>>> 
>> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7322 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130823/28146943/attachment.bin>