Barnyard2 is suddenly stopped. (Suricata)



  • Hi.

    I enable barnyard2 with suricata with 3.0_7 and use syslog output, My barnyard2 is suddenly stoped at Jun 30 08:49:16.

    Jun 30 08:49:16	kernel		pid 48285 (barnyard2), uid 0: exited on signal 11 (core dumped)
    

    I try restart suricata, But It's not working, It suddenly stop for a while.

    Jun 30 09:47:11	kernel		pid 49578 (barnyard2), uid 0: exited on signal 11 (core dumped)
    Jun 30 09:47:01	barnyard2	49578	There's no second layer header available for this datalink
    Jun 30 09:47:01	barnyard2	49578	Opened spool file '/var/log/suricata/suricata_ix035030/unified2.alert.1467201859'
    Jun 30 09:47:01	barnyard2	49578	Using waldo file '/var/log/suricata/suricata_ix035030/barnyard2/35030_ix0.waldo': spool directory = /var/log/suricata/suricata_ix035030 spool filebase = unified2.alert time_stamp = 1467201859 record_idx = 49793
    Jun 30 09:47:01	barnyard2	49578	Barnyard2 initialization completed successfully (pid=49578)
    Jun 30 09:47:01	barnyard2	49578	--== Initialization Complete ==--
    Jun 30 09:47:01	barnyard2	49578	Writing PID "49578" to file "/var/run/barnyard2_ix035030.pid"
    Jun 30 09:47:01	barnyard2	49578	PID path stat checked out ok, PID path set to /var/run
    Jun 30 09:47:01	barnyard2	49578	Daemon initialized, signaled parent pid: 49305
    Jun 30 09:47:01	barnyard2	49305	Daemon parent exiting
    Jun 30 09:47:01	barnyard2	49305	Initializing daemon mode
    Jun 30 09:47:01	barnyard2	49305	Reporting Protocol: udp
    Jun 30 09:47:01	barnyard2	49305	Syslog Server: 163.22.168.17:514
    Jun 30 09:47:01	barnyard2	49305	Detail Level: Fast
    Jun 30 09:47:01	barnyard2	49305	spo_syslog_full config:
    Jun 30 09:47:01	barnyard2	49305	using operation_mode: default
    Jun 30 09:47:01	barnyard2	49305	Log directory = /var/log/suricata/suricata_ix035030
    Jun 30 09:47:01	barnyard2	49305	Barnyard2 spooler: Event cache size set to [4096]
    Jun 30 09:47:01	barnyard2	49305	---------------------------- +[ Signature Suppress list ]+
    Jun 30 09:47:01	barnyard2	49305	+[No entry in Signature Suppress List]+
    Jun 30 09:47:01	barnyard2	49305	+[ Signature Suppress list ]+ ----------------------------
    Jun 30 09:47:01	barnyard2	49305	Found pid path directive (/var/run)
    Jun 30 09:47:01	barnyard2	49305	Parsing config file "/usr/local/etc/suricata/suricata_35030_ix0/barnyard2.conf"
    Jun 30 09:47:01	barnyard2	49305	Initializing Output Plugins!
    Jun 30 09:47:01	barnyard2	49305	Initializing Input Plugins!
    Jun 30 09:47:01	barnyard2	49305	--== Initializing Barnyard2 ==--
    Jun 30 09:47:01	barnyard2	49305	Running in Continuous mode
    Jun 30 09:47:01	barnyard2	49305	Found pid path directive (/var/run)
    Jun 30 09:47:01	SuricataStartup	49131	Barnyard2 START for WAN(35030_ix0)...
    Jun 30 09:47:00	SuricataStartup	47572	Suricata START for WAN(35030_ix0)...
    

    pid 79970 (barnyard2), uid 0: exited on signal 11 (core dumped)

    I remove unified2.alert.1467201859 spool file and restart suricata, barnyard2 start again.

    Any suggestion??

    Thank!



  • First question is what platform are you running pfSense on?  Is a regular hard disk full install or is it a NanoBSD image?

    If NanoBSD, you may be running out of disk space on the /var/log partition.  At any rate, if Barnyard2 started once you removed that particular spool file, then that file somehow got corrupted is my guess.

    Bill



  • Hi.

    It's regular hard disk full install, Barnyard2 stop again suddenly today. Unified2.alert is writed log continuously.

    Barnyard2 have debug mode by CLI?



  • No, there is no CLI debugging that I am aware of.  I had so many issues with Barnyard2 that I just stopped using it on my personal firewall.  It has not been updated in the FreeBSD ports tree for quite some time.  I don't have another alternative to suggest, but I would not really recommend using Barnyard2 right now because it has several issues in my opinion.  It goes crazy with CPU utilization after rules updates as it does a ton of SQL stuff in the database, it seems to randomly choke on stuff and just stop, and it has issues with referential integrity violations in the database when the references within Snort rules get reordered during updates.

    Bill