Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In an audit of queries running on our databases using tcpdump and Maatkit tools, the number one query is

RESET [int]

Running this statement from the MySQL command line results in an error as RESET should only accept parameters master, query cache and slave.

This statement does not exist in our code base. We do run MySQL Enterprise Monitor but the reported user is not our monitoring user. We also use the Zend framework with the mysqli connection driver but failed to find any call to this statement.

Any ideas as to what this could be?

share|improve this question
Think about what has access to those credentials; only something that does can be generating this error. For bonus points, try swapping the credentials used by your web services, and see if the source uid of the RESETs changes. – BMDan Apr 12 '11 at 12:55
up vote 2 down vote accepted

I suspect that this is mk-query-digest misinterpreting the TCP traffic. Reconstructing the traffic as an observer on the sidelines, due to out-of-order packets, dropped packets, retransmits, and so on, is never an exact science. When there are a lot of errors in what mk-query-digest sees, it can sometimes interpret the traffic in spurious ways and appear to find things that might not exist.

I would suggest digging into the tcpdump output manually. It is tedious, and the protocol is hard to decode manually, but if you dump some data to a file and then mk-query-digest it, mk-query-digest will tell you the byte offset in the file where it finds the sample query it prints out. This should let you narrow in on one packet, and with the protocol docs from the MySQL internals manual, you ought to be able to see if that packet really is the alleged RESET. I believe that the RESET is probably related to the binary (prepared statement) protocol, if it's real; if it's spurious, I have no guesses.

share|improve this answer
Thanks for the suggestion. I eventually wrote it off as a mis-constructed query as I could not find any source. – sreimer Sep 1 '11 at 3:55

You're using tcpdump, so you can narrow this down by finding which workstation(s) this is coming from. If it's all of them, then there's something wrong with your assumptions.

share|improve this answer
It's reported as coming from all of our web servers. I'm not saying it's not code related, but it doesn't seem to be explicitly called. I'm wondering if there is an automatic mechanism triggering this. – sreimer Mar 23 '11 at 21:22

If you're watching it with tcpdump, you should be able to know the user who's logging in and the source port. The former gives you the ability to change credentials one-by-one until the problematic queries change which login they use, at which point you'll know their source. The source port lets you both know whether the remote UID is zero (if src port is <1024), and it also gives you the ability to use netstat -ntp (*nix) or netstat -nto (Windows) to determine which PID is actually generating the query.

share|improve this answer
tcpdump was run on 3306 to get only MySQL traffic. The actual queries were rebuilt from that dump using mk-query-digest. I am doing some deeper analysis with the dump. – sreimer Mar 24 '11 at 3:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.