[Note to Moderator: Resending with less data since the previous one was too long]
Hi,
We have been seeing this logger crash with Bro 2.5 running on a PPC based system. I have included the diag output from broctl below. It seems to be related to the rate at which logs are generated – the higher the rate (corresponding to more incoming traffic) the sooner the crash occurs. The CPU on which the logger runs has only about 4GB of memory, out of which approximately 1.5GB is available to the logger. As the logs below show, tc_malloc() does fail to allocate memory a few times, and I am guessing that the disks are not able to keep up with the logging rate.
Is the logger capable of recovering from memory allocation failure? If so, does the trace below indicate any other issue? Would appreciate any suggestions and/or insight into the problem.
Thanks,
Raj
We have been seeing this logger crash with Bro 2.5 running on a PPC
based system. I have included the diag output from broctl below. It
seems to be related to the rate at which logs are generated - the higher
the rate (corresponding to more incoming traffic) the sooner the crash
occurs. The CPU on which the logger runs has only about 4GB of memory,
out of which approximately 1.5GB is available to the logger. As the logs
below show, tc_malloc() does fail to allocate memory a few times, and I
am guessing that the disks are not able to keep up with the logging
rate.
Yup, that sounds like a reasonable guess from your description.
Is the logger capable of recovering from memory allocation failure? If
so, does the trace below indicate any other issue? Would appreciate any
suggestions and/or insight into the problem.
No, it is not - Bro generally is not able to recover from memory
allocation failures.
I can't really tell anything else from the attached backtrace - they stop
a bit too early to be useful.
I hope this helps,
Johanna