Interrupting query sends wrong thread ID In the MySQL command line client (Linux) when I kill a query by pressing CTRL+c this usually works fine.

mysql (slave) &gt; select sleep(5);
^CCtrl-C -- sending "KILL QUERY 117920686" to server ...
Ctrl-C -- query aborted.
+----------+
| sleep(5) |
+----------+
+----------+
1 row in set (0.78 sec)


However when I do the same on my live master server (of all servers it must be this one...) it somehow sends the wrong thread ID.

mysql (master) &gt; select sleep(5);
^CCtrl-C -- sending "KILL QUERY 770543254" to server ...
Ctrl-C -- query aborted.
+----------+
| sleep(5) |
+----------+
+----------+
1 row in set (5.00 sec) /* &lt;- it obviously hasn't aborted at all */


The ID is way too low. Other threads have IDs like 26534760326. All servers are of the same version:

# yum list installed mysql*
Loaded plugins: dellsysid, rhnplugin, security, ulninfo
This system is receiving updates from RHN Classic or Red Hat Satellite.
Installed Packages
MySQL-python.x86_64                                             1.2.3-0.3.c1.1.el6                              @public_ol6_latest
mysql-community-client.x86_64                                   5.6.27-2.el6                                    @mysql56-community
mysql-community-common.x86_64                                   5.6.27-2.el6                                    @mysql56-community
mysql-community-libs.x86_64                                     5.6.27-2.el6                                    @mysql56-community
mysql-community-libs-compat.x86_64                              5.6.27-2.el6                                    @mysql56-community
mysql-community-release.noarch                                  el6-5                                           @/mysql-community-release-el6-5.noarch
mysql-community-server.x86_64                                   5.6.27-2.el6                                    @mysql56-community


Additional info: 

The connection_id() function returns the right value however.

root@ods01:(none) &gt; select connection_id();
+-----------------+
| connection_id() |
+-----------------+
|     26542310314 |
+-----------------+
1 row in set (0.00 sec)

root@ods01:(none) &gt; select sleep(5);
^CCtrl-C -- sending "KILL QUERY 772506538" to server ...
Ctrl-C -- query aborted.
+----------+
| sleep(5) |
+----------+
+----------+
1 row in set (5.00 sec)


Does anyone know how to fix this?
Write a bug report!  http://bugs.mysql.com.
  26542310314 MOD 2^32 = 772506538

That is, the 64-bit connection_id was chopped to 32 bits to send the KILL, thereby sending it to the wrong id.
Not many users get past 4 billion connections.  How long has your server been up?  I hope the code is not reconnecting for every query.
Change logs

----- 2014-09-25 5.7.5 Milestone 15 -- Bugs Fixed -- -----
Connection IDs are 32-bit unsigned integers, beginning at 1. When the server assigns connection IDs and reaches the top of the 32-bit range, it rolls the value over to begin at 1 again. It was possible that the server would assign a connection ID to a new thread while that ID was still in use by an existing thread, if the old thread was particularly long running. For such cases, reference to the ID becomes ambiguous. For example, it cannot reliably be determined for KILL connection_id which thread to kill, which could lead to undefined behavior. This behavior has been corrected so that in-use IDs are not reused.
Connection IDs are 32-bit unsigned integers, beginning at 1. When the server assigns connection IDs and reaches the top of the 32-bit range, it rolls the value over to begin at 1 again. It was possible that the server would assign a connection ID to a new thread while that ID was still in use by an existing thread, if the old thread was particularly long running. For such cases, reference to the ID becomes ambiguous. For example, it cannot reliably be determined for KILL connection_id which thread to kill, which could lead to undefined behavior. This behavior has been corrected so that in-use IDs are not reused.
----- 2012-12-11 5.6.9 Release Candidate -- Bugs Fixed -- Incompatible Change -----
Connection ID (thread ID) values greater than 32 bits can occur on
some systems (such as busy or long-running 64-bit systems), causing
these problems:
Connection IDs written to the general query log and slow query log
were incorrect. This was true for logging to both files and tables.
The
CONNECTION_ID()
function could return a value with a data type too small for values
larger than 32 bits.
The
mysql_thread_id()
and
mysql_kill()
C API functions did not handle ID values larger than 32 bits. This
could result in killing the wrong thread; for example, if you invoked
mysql_kill(mysql_thread_id()).
Connection IDs now are permitted to be 64-bit values when the server
supports them (when built with 64-bit data types), which has these
effects:
Connection IDs are logged correctly to the general query log and slow
query log.
Note This change involves a modification to the log tables, so after
upgrading to this release, you must run mysql_upgrade and restart the
server.
CONNECTION_ID()
returns a data type appropriate for values larger than 32 bits.
mysql_thread_id()
is unchanged; the client/server protocal has only 4 bytes for the ID
value. This function returns an incorrect (truncated) value for
connection IDs larger than 32 bits and should be avoided.
mysql_kill()
still cannot handle values larger than 32 bits, but to guard against
killing the wrong thread now returns an error in these cases:
If given an ID larger than 32 bits,
mysql_kill()
returns a
CR_INVALID_CONN_HANDLE
error.
After the server's internal thread ID counter reaches a value larger
than 32 bits, it returns an
ER_DATA_OUT_OF_RANGE
error for any
mysql_kill()
invocation and
mysql_kill()
fails.
To avoid problems with
mysql_thread_id()
and
mysql_kill(),
do not use them. To get the connection ID, execute a SELECT
CONNECTION_ID() query and retrieve the result. To kill a thread,
execute a KILL statement.
(Bug #19806, Bug #11745768, Bug #65715, Bug #14236124, Bug #44728, Bug #11753308)

(Small bug numbers can be found at bugs.mysql.com; large bug numbers are inaccessible - internal to Oracle.)
So, recommend you upgrade to 5.6.9+ or 5.7.5+.  Since you are on 5.6.27, there is a puzzle.  Maybe some detail in that lengthy Changelog says something useful.