[Snort-users] mysql database "gone away"

David Ryan David.Ryan at ...13912...
Mon Jul 16 10:17:02 EDT 2007

I know this has been posted about a few times, but I am still a little lost as to what I can change to stop the database connection going away when there is a network problem or other sort of one-off connectivity issue between the snort sensor and the mysql database it is connecting to.

>From what I have read on the topic the problem is a function of the database connectivity model between the client (snort probe) and the mysql server.  When the connection drops nothing ever tells the client to re-try the connection.  It just says the connection is down, I can't write this data, thank you and goodnight . . .

Obviously it would be nice if some process could be configured to retry this connection and get the data back to the server.  What do other people use to get over this problem ?  I mean, if you have a connectivity problem into your data centre and you lose connectivty to all your probes, do people really manually log into each remote probe and restart the service ?  It just seems a bit . . . manual.  I accept that it is a limitation of the mysql client in use, but in practical terms what do people do to ensure the database link doesn't stay down for hours(days/weeks) after a temporary glitch like this ?



Hi Greg,

> I posted this on the forums a few days ago but since there has been no

> replies I am asking anyone on this list for assistance.



> Most of my sensors are running on centos 4 without a problem using

> mysql and base. To start getting familiar with CentOS 5 i built a test

> sensor which comes with mysql 5. I compiled the latest snort 2.6.x version.


> What happens if I do not get any alarms is snort loses the connection

> and starts throwing various errors like


> snort[7890]: database: mysql_error: MySQL server has gone away


> The database is working fine. I can still connect to it.

either a timeout happened or the connection was otherwise terminated. The client library of MySQL 4.x did a reconnect whereas this behaviour was changed with version 5.x.

Take a look at:


Best regards


**********************  IMPORTANT--PLEASE READ  ************************
This electronic message, including its attachments, is COMPANY CONFIDENTIAL
and may contain PROPRIETARY or LEGALLY PRIVILEGED information.  If you are 
not the intended recipient, you are hereby notified that any use, disclosure,
copying, or distribution of this message or any of the information included
in it is unauthorized and strictly prohibited.  If you have received this
message in error, please immediately notify the sender by reply e-mail and
permanently delete this message and its attachments, along with any copies
thereof. If this electronic message contains a zipped attachment and you do
not have a decompression tool, you may download unZIP (free of cost) from:
http://www.mk-net-work.com/us/uz/unzip.htm. Alternatively, you may request
that the attachment be resent in an uncompressed format.        Thank you. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20070716/40e978cf/attachment.html>

More information about the Snort-users mailing list