[Snort-users] Barnyard2 Failing on Write to SQL Database

Jim Campbell jim at w4bqp.net
Wed Feb 7 16:37:04 EST 2018

Thank you, Marcin, I appreciate your prompt reply. I will check into the 
questions you asked. Some of the terms are new to me, such as json.

This problem cropped up a couple of weeks ago and I suspected that there 
was a change in the rules file that I didn't notice.

I had both Snort and Snort+ installed perhaps six months ago. 
Snort+ was giving me problems and was working so I quit playing 
with Snort+

I suspect that the most expedient thing for me to do is to bring Snort 
+/3 up to date and try Evebox.

Thanks again,


On 2/7/2018 3:40 PM, Marcin Dulak wrote:
> On Wed, Feb 7, 2018 at 8:41 PM, Jim Campbell <jim at w4bqp.net 
> <mailto:jim at w4bqp.net>> wrote:
>     I am having recurring failures of Barnyard2 to write to the SQL
>     database. I am running Snort on a Ubuntu 17.04 computer in
>     inline mode. I modify the rules file /etc/snort/rules/snortd.rules
>     to block packets rather than alert on them.
>     Each time the failure occurrs, the /var/log/snort/snort.u2... file
>     contains the same records at the beginning. I will add the
>     beginning of the u2 file below.  Further down in the u2 file
>     (below) it mentions a Silverlight update but the GID and SID don't
>     match the ones in the u2 file.-
>     Snort continues to run and write to the u2 file but since
>     Barnyard2 is in a failed state I get nothing from Base.
>     ========================================================
>     My command line for Snort is: /usr/local/bin/snort -Q -q -u snort
>     -g snort -c /etc/snort/snort.conf -i enp1s0:enp4s0
>     My command line for Barnyard2 is: /usr/local/bin/barnyard2 -c
>     /etc/snort/barnyard2.conf -d /var/log/snort -f snort.u2 -q -w
>     /var/log/snort/barnyard2.waldo -a /var/log/snort/archived_logs/ -u
>     root -g snort
>     When I query the status of Barnyard2 after a failure I get:
>     ● barnyard2.service - Barnyard2 Daemon
>        Loaded: loaded (/lib/systemd/system/barnyard2.service; enabled;
>     vendor preset: enabled)
>        Active: failed (Result: exit-code) since Mon 2018-02-05
>     14:48:30 EST; 57min ago
>      Main PID: 27146 (code=exited, status=1/FAILURE)
>     Feb 05 14:21:06 jim-IPS systemd[1]: Started Barnyard2 Daemon.
>     Feb 05 14:48:30 jim-IPS barnyard2[27146]: ERROR: database
>     mysql_error: Duplicate entry '69943-1' for key 'PRIMARY'
>     Feb 05 14:48:30 jim-IPS barnyard2[27146]: SQL=[INSERT INTO
>     sig_reference (ref_id,sig_id,ref_seq) VALUES ('152087','69943','1');]
>     Feb 05 14:48:30 jim-IPS barnyard2[27146]: Fatal Error, Quitting..
>     Feb 05 14:48:30 jim-IPS systemd[1]: barnyard2.service: Main
>     process exited, code=exited, status=1/FAILURE
>     Feb 05 14:48:30 jim-IPS systemd[1]: barnyard2.service: Unit
>     entered failed state.
>     Feb 05 14:48:30 jim-IPS systemd[1]: barnyard2.service: Failed with
>     result 'exit-code'.
> since mysql claims it's duplicate maybe you can examine the contents 
> of the tables to see what 69943 corresponds to?
> Other people reported that problem 
> https://github.com/firnsy/barnyard2/issues/208 but since barnyard is 
> dead probably nobody will answer.
> I imagine mysql will start fine from that state, maybe you just need 
> to modify the systemd service file to restart the failed mysql 
> automatically and setup a monitoring system so you know how often this 
> happens:
> [Service]
> Restart=on-failure
> But really, look for a modern log analysis system and try 
> https://github.com/jasonish/evebox
> Hopefully is not too late for evebox to support snort.
> By the way is snort 2.9 able to log into json directly? 
> http://blog.snort.org/2017/11/snort-30-with-elasticsearch-logstash.html
> Marcin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20180207/8e595219/attachment.html>

More information about the Snort-users mailing list