mysql database "gone away"

[David Ryan <David.Ryan () Quintiles com>]

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 ?

Thanks,

David



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:



  http://osdir.com/ml/security.ids.snort.devel/2006-04/msg00001.html



Best regards



Dirk


**********************  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. 
************************************************************************

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users