[Oisf-devel] suricata 1.3.4 coredump caused by segfault
xbadou xbadou
xbadou at gmail.com
Fri Nov 30 02:50:50 UTC 2012
Thank you very much.
But I want to known, whether I can do something to limit the max memory
usage of suricata. Because I just have very small network traffic. I
think 4 GB is maybe enough to me. I just want suricata keep alive if it
can't get more memory. Or suricata do some memory clean jobs if it can't
allocate more memory.
If suricata get a segfault very offen, I think I may need a watchdog to
watch this and restart it.
On Fri, Nov 30, 2012 at 10:26 AM, Marcos Rodriguez <
marcos.e.rodriguez at gmail.com> wrote:
>
>
> On Thu, Nov 29, 2012 at 8:23 PM, xbadou xbadou <xbadou at gmail.com> wrote:
>
>> Yes, I am running debian 5 with kernel 2.6.31.14 32bit。 And the system
>> ram size is 2GB*2.
>>
>> So, if it is really this issue. How can I avoid this coredump happen? Can
>> I change some settings in the suricata.yaml file?
>>
>> Thanks.
>>
>
>
> At the bottom of the suricata.yaml file, you'll find this section:
>
> # Suricata core dump configuration. Limits the size of the core dump file
> to
> # approximately max-dump. The actual core dump size will be a multiple of
> the
> # page size. Core dumps that would be larger than max-dump are truncated.
> On
> # Linux, the actual core dump size may be a few pages larger than max-dump.
> # Setting max-dump to 0 disables core dumping.
> # Setting max-dump to 'unlimited' will give the full core dump file.
> # On 32-bit Linux, a max-dump value >= ULONG_MAX may cause the core dump
> size
> # to be 'unlimited'.
>
> coredump:
> max-dump: unlimited
>
> Change the max-dump to 0 to disable. :o)
>
> marcos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-devel/attachments/20121130/29de2215/attachment-0002.html>
More information about the Oisf-devel
mailing list