[Oisf-devel] suricata 1.3.4 coredump caused by segfault
xbadou xbadou
xbadou at gmail.com
Wed Dec 5 12:25:18 UTC 2012
Hi，
It seems that 1.3-dev works well for a whole day. After it starts, the
memory usage slowly increase. When the usage is above 80%, it remains
unchanged for a long time.
There isn’t any coredump file too. Everything is all right. But I find that
there are some logs as follows.
...
[2735] 5/12/2012 -- 14:00:09 - (flow-manager.c:517) <Info>
(FlowManagerThread) -- Flow emergency mode over, back to normal...
unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1354687208, ts.tv_usec:789402)
flow_spare_q status(): 1408% flows at the queue
[2735] 5/12/2012 -- 14:01:30 - (flow-manager.c:517) <Info>
(FlowManagerThread) -- Flow emergency mode over, back to normal...
unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1354687290, ts.tv_usec:645263)
flow_spare_q status(): 1263% flows at the queue
[2735] 5/12/2012 -- 14:02:34 - (flow-manager.c:517) <Info>
(FlowManagerThread) -- Flow emergency mode over, back to normal...
unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1354687354, ts.tv_usec:263409)
flow_spare_q status(): 1181% flows at the queue
[2735] 5/12/2012 -- 14:03:11 - (flow-manager.c:517) <Info>
(FlowManagerThread) -- Flow emergency mode over, back to normal...
unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1354687391, ts.tv_usec:535048)
flow_spare_q status(): 1388% flows at the queue
[2735] 5/12/2012 -- 14:03:46 - (flow-manager.c:517) <Info>
(FlowManagerThread) -- Flow emergency mode over, back to normal...
unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1354687426, ts.tv_usec:697482)
flow_spare_q status(): 1093% flows at the queue
[2735] 5/12/2012 -- 14:04:06 - (flow-manager.c:517) <Info>
(FlowManagerThread) -- Flow emergency mode over, back to normal...
unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1354687446, ts.tv_usec:541106)
flow_spare_q status(): 1010% flows at the queue
[2735] 5/12/2012 -- 14:04:38 - (flow-manager.c:517) <Info>
(FlowManagerThread) -- Flow emergency mode over, back to normal...
unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1354687478, ts.tv_usec:503235)
flow_spare_q status(): 1406% flows at the queue
[2735] 5/12/2012 -- 14:05:19 - (flow-manager.c:517) <Info>
(FlowManagerThread) -- Flow emergency mode over, back to normal...
unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1354687518, ts.tv_usec:764832)
flow_spare_q status(): 1184% flows at the queue
...
I will run it for some days to see whether anything else happens.
Thanks.
On Mon, Dec 3, 2012 at 10:54 PM, Victor Julien <victor at inliniac.net> wrote:
> On 12/03/2012 03:38 AM, xbadou xbadou wrote:
> > Hi,
> >
> > I use 'top' command, my memory is as follows:
> >
> > Mem: 3080880k total, 356708k used, 2724172k free, 6452k buffers
> > Swap: 2650684k total, 0k used, 2650684k free, 83212k cached
> >
> > When suricata starts, it used about 6.6% (~203MB). But it become larger
> > and larger.
> >
> > The following is some log when suricata starts.
> >
> > 3/12/2012 -- 08:44:50 - <Info> - AutoFP mode using default "Active
> > Packets" flow load balancer
> > 3/12/2012 -- 08:44:50 - <Info> - Use pid file /var/run/suricata.pid from
> > config file.
> > 3/12/2012 -- 08:44:50 - <Info> - preallocated 5000 packets. Total memory
> > 15440000
> > 3/12/2012 -- 08:44:50 - <Info> - allocated 131072 bytes of memory for
> > the host hash... 4096 buckets of size 32
> > 3/12/2012 -- 08:44:50 - <Info> - preallocated 1000 hosts of size 72
> > 3/12/2012 -- 08:44:50 - <Info> - host memory usage: 203072 bytes,
> > maximum: 16777216
> > 3/12/2012 -- 08:44:50 - <Info> - allocated 2097152 bytes of memory for
> > the flow hash... 65536 buckets of size 32
> > 3/12/2012 -- 08:44:50 - <Info> - preallocated 10000 flows of size 176
> > 3/12/2012 -- 08:44:50 - <Info> - flow memory usage: 3857152 bytes,
> > maximum: 33554432
> > 3/12/2012 -- 08:44:50 - <Info> - using magic-file /usr/share/file/magic
> > 3/12/2012 -- 08:44:53 - <Error> - [ERRCODE:
> > SC_ERR_UNKNOWN_DECODE_EVENT(191)] - unknown decode event
> > "ipv6.ipv4_in_ipv6_too_small"
> > 3/12/2012 -- 08:44:53 - <Error> - [ERRCODE:
> > SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert pkthdr
> > any any -> any any (msg:"SURICATA IPv4-in-IPv6 packet too short";
> > decode-event:ipv6.ipv4_in_ipv6_too_small; sid:2200082; rev:1;)" from
> > file /etc/suricata/rules/decoder-events.rules at line 93
> > 3/12/2012 -- 08:44:53 - <Error> - [ERRCODE:
> > SC_ERR_UNKNOWN_DECODE_EVENT(191)] - unknown decode event
> > "ipv6.ipv4_in_ipv6_wrong_version"
> > 3/12/2012 -- 08:44:53 - <Error> - [ERRCODE:
> > SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert pkthdr
> > any any -> any any (msg:"SURICATA IPv4-in-IPv6 invalid protocol";
> > decode-event:ipv6.ipv4_in_ipv6_wrong_version; sid:2200083; rev:1;)" from
> > file /etc/suricata/rules/decoder-events.rules at line 94
> > 3/12/2012 -- 08:44:53 - <Error> - [ERRCODE:
> > SC_ERR_UNKNOWN_DECODE_EVENT(191)] - unknown decode event
> > "ipv6.ipv6_in_ipv6_too_small"
> > 3/12/2012 -- 08:44:53 - <Error> - [ERRCODE:
> > SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert pkthdr
> > any any -> any any (msg:"SURICATA IPv6-in-IPv6 packet too short";
> > decode-event:ipv6.ipv6_in_ipv6_too_small; sid:2200084; rev:1;)" from
> > file /etc/suricata/rules/decoder-events.rules at line 96
> > 3/12/2012 -- 08:44:53 - <Error> - [ERRCODE:
> > SC_ERR_UNKNOWN_DECODE_EVENT(191)] - unknown decode event
> > "ipv6.ipv6_in_ipv6_wrong_version"
> > 3/12/2012 -- 08:44:53 - <Error> - [ERRCODE:
> > SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert pkthdr
> > any any -> any any (msg:"SURICATA IPv6-in-IPv6 invalid protocol";
> > decode-event:ipv6.ipv6_in_ipv6_wrong_version; sid:2200085; rev:1;)" from
> > file /etc/suricata/rules/decoder-events.rules at line 97
> > 3/12/2012 -- 08:44:53 - <Error> - [ERRCODE:
> > SC_ERR_OPENING_RULE_FILE(41)] - opening rule file
> > /etc/suricata/rules/emerging-botcc.rules: No such file or directory.
> > 3/12/2012 -- 08:44:53 - <Error> - [ERRCODE:
> > SC_ERR_OPENING_RULE_FILE(41)] - opening rule file
> > /etc/suricata/rules/emerging-ciarmy.rules: No such file or directory.
> > 3/12/2012 -- 08:44:53 - <Error> - [ERRCODE:
> > SC_ERR_OPENING_RULE_FILE(41)] - opening rule file
> > /etc/suricata/rules/emerging-compromised.rules: No such file or
> directory.
> > 3/12/2012 -- 08:44:53 - <Error> - [ERRCODE:
> > SC_ERR_OPENING_RULE_FILE(41)] - opening rule file
> > /etc/suricata/rules/emerging-drop.rules: No such file or directory.
> > 3/12/2012 -- 08:44:53 - <Error> - [ERRCODE:
> > SC_ERR_OPENING_RULE_FILE(41)] - opening rule file
> > /etc/suricata/rules/emerging-dshield.rules: No such file or directory.
> > 3/12/2012 -- 08:44:53 - <Error> - [ERRCODE:
> > SC_ERR_OPENING_RULE_FILE(41)] - opening rule file
> > /etc/suricata/rules/emerging-tor.rules: No such file or directory.
> > 3/12/2012 -- 08:44:53 - <Info> - 41 rule files processed. 6106 rules
> > succesfully loaded, 4 rules failed
> > 3/12/2012 -- 08:44:54 - <Info> - 6114 signatures processed. 4 are
> > IP-only rules, 2880 are inspecting packet payload, 3885 inspect
> > application layer, 72 are decoder event only
> > 3/12/2012 -- 08:44:54 - <Info> - building signature grouping structure,
> > stage 1: adding signatures to signature source addresses... complete
> > 3/12/2012 -- 08:44:54 - <Info> - building signature grouping structure,
> > stage 2: building source address list... complete
> > 3/12/2012 -- 08:44:56 - <Info> - building signature grouping structure,
> > stage 3: building destination address lists... complete
> > 3/12/2012 -- 08:44:57 - <Warning> - [ERRCODE: SC_ERR_FOPEN(44)] - Error
> > opening file: "/etc/suricata//threshold.config": No such file or
> directory
> > 3/12/2012 -- 08:44:57 - <Info> - Core dump size is unlimited.
> > 3/12/2012 -- 08:44:57 - <Info> - fast output device (regular)
> > initialized: fast.log
> > 3/12/2012 -- 08:44:57 - <Info> - Unified2-alert initialized: filename
> > unified2.alert, limit 32 MB
> > 3/12/2012 -- 08:44:57 - <Info> - Using 1 live device(s).
> > 3/12/2012 -- 08:44:57 - <Info> - Unable to find pcap config for
> > interface wafbridge1, using default value
> > 3/12/2012 -- 08:44:57 - <Info> - using interface wafbridge1
> > 3/12/2012 -- 08:44:57 - <Info> - RunModeIdsPcapAutoFp initialised
> > 3/12/2012 -- 08:44:57 - <Info> - stream "max-sessions": 262144
> > 3/12/2012 -- 08:44:57 - <Info> - stream "prealloc-sessions": 32768
> > 3/12/2012 -- 08:44:57 - <Info> - stream "memcap": 33554432
> > 3/12/2012 -- 08:44:57 - <Info> - stream "midstream" session pickups:
> > disabled
> > 3/12/2012 -- 08:44:57 - <Info> - stream "async-oneside": disabled
> > 3/12/2012 -- 08:44:57 - <Info> - stream "checksum-validation": enabled
> > 3/12/2012 -- 08:44:57 - <Info> - stream."inline": disabled
> > 3/12/2012 -- 08:44:57 - <Info> - stream.reassembly "memcap": 67108864
> > 3/12/2012 -- 08:44:57 - <Info> - stream.reassembly "depth": 1048576
> > 3/12/2012 -- 08:44:57 - <Info> - stream.reassembly
> > "toserver-chunk-size": 2560
> > 3/12/2012 -- 08:44:57 - <Info> - stream.reassembly
> > "toclient-chunk-size": 2560
> > 3/12/2012 -- 08:44:57 - <Info> - all 7 packet processing threads, 3
> > management threads initialized, engine started.
> >
> >
> > My testing network is like this.
> >
> > Working Network ------Suricata-------Internet
> >
> > Working Network bandwidth is about 8~30Mbit/s. Each traffic we visit
> > Internet is checked by Suricata.
>
> Could you try upgrading to our 1.3-dev branch here:
> https://github.com/inliniac/suricata/tree/master-1.3.x
>
> We fixed a memory leak in our flow engine that may be related to the
> issue you are having.
>
> Cheers,
> Victor
>
>
> >
> > Thank you.
> >
> >
> >
> > On Fri, Nov 30, 2012 at 6:44 PM, Peter Manev <petermanev at gmail.com
> > <mailto:petermanev at gmail.com>> wrote:
> >
> > Hi,
> >
> > You mention that you have small traffic - how much memory does
> > Suricata use? how many rules do you load?
> >
> > thank you
> >
> > On Fri, Nov 30, 2012 at 3:50 AM, xbadou xbadou <xbadou at gmail.com
> > <mailto:xbadou at gmail.com>> wrote:
> >
> > 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
> > <mailto:marcos.e.rodriguez at gmail.com>> wrote:
> >
> >
> >
> > On Thu, Nov 29, 2012 at 8:23 PM, xbadou xbadou
> > <xbadou at gmail.com <mailto: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
> >
> >
> >
> > _______________________________________________
> > Suricata IDS Devel mailing list:
> > oisf-devel at openinfosecfoundation.org
> > <mailto:oisf-devel at openinfosecfoundation.org>
> > Site: http://suricata-ids.org | Participate:
> > http://suricata-ids.org/participate/
> > List:
> >
> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
> > Redmine: https://redmine.openinfosecfoundation.org/
> >
> >
> >
> >
> > --
> > Regards,
> > Peter Manev
> >
> >
> >
> >
> > _______________________________________________
> > Suricata IDS Devel mailing list: oisf-devel at openinfosecfoundation.org
> > Site: http://suricata-ids.org | Participate:
> http://suricata-ids.org/participate/
> > List:
> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
> > Redmine: https://redmine.openinfosecfoundation.org/
> >
>
>
> --
> ---------------------------------------------
> Victor Julien
> http://www.inliniac.net/
> PGP: http://www.inliniac.net/victorjulien.asc
> ---------------------------------------------
>
> _______________________________________________
> Suricata IDS Devel mailing list: oisf-devel at openinfosecfoundation.org
> Site: http://suricata-ids.org | Participate:
> http://suricata-ids.org/participate/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
> Redmine: https://redmine.openinfosecfoundation.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-devel/attachments/20121205/e1129a2b/attachment-0002.html>
More information about the Oisf-devel
mailing list