I also think it would be quite useful to test packages before
installing them, that gives a chance to catch problems before changing
anything (including things like: missing/broken/wrong dependencies;
lack of something OS-specific the package needs (say, it's a
Linux-only plugin); generally things
So I am running a new detection package and everything seemed right but somehow
since yesterday each worker is running at 5.7% to 6.3% CPU and not generating
logs.
The backtrace shows the following and how much (%) CPU is spending on what
functions.
Can someone help me read why might BRO spen
Hi Aashish,
> So I am running a new detection package and everything seemed right but
> somehow since yesterday each worker is running at 5.7% to 6.3% CPU and not
> generating logs.
my guess would be that the script makes (heavy) use of tables and table
expiration, right? Can you share the scri
> On Jan 18, 2017, at 12:29 PM, Aashish Sharma wrote:
>
> So I am running a new detection package
It was stable before you added the new scripts? Are the new scripts publicly
available?
--
- Justin Azoff
___
bro-dev mailing list
bro-dev@bro.or
Yes, I have been making heavy use of tables ( think a million entries a day and
million expires a day)
Let me figure out a way to upload the scripts on github or send them yours and
justin's way otherwise.
Strangely this code kept running fine for last month and reasonably stable. I
am not s
Yeah.. lots of expires may have something to do with it, your traceback shows
TableEntryVal16ExpireAccessTimeEv
But I also wonder what you are doing that is triggering
Dictionary9NextEntryERP7HashKeyRP10IterCookiei
which would be
void* Dictionary::NextEntry(HashKey*& h, IterCookie*& cookie, in