MySQL Bugs: #63988: Kill - doesnt kill the Mysql process

Bug #63988	Kill - doesnt kill the Mysql process - just doubles it's usage
Submitted:	11 Jan 2012 7:16	Modified:	14 Jan 2012 4:12
Reporter:	Ron Gully	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: General	Severity:	S3 (Non-critical)
Version:	5.0.92-community	OS:	Linux
Assigned to:		CPU Architecture:	Any

Description:
The application we run opens the database and creates a process as below

/usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/server2.auctionsau.com.pid --skip-external-locking

This process progressively uses more and more CPU resources, over a period of weeks, until it shuts the server down.  See the trace below - it goes forever.

If you try to kill the process it returns instantly using exactly double the CPU resources.  Try killing it 3 or 4 times and the server crashes.

Is this a bug or can anyone help with a suggestion?

Process 3263 attached - interrupt to quit
select(13, [10 12], NULL, NULL, NULL)   = 1 (in [12])
fcntl(12, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
accept(12, {sa_family=AF_FILE, path="\7\361<\326\351\222"...}, [8516025424675864578]) = 24
fcntl(12, F_SETFL, O_RDWR)              = 0
getsockname(24, {sa_family=AF_FILE, path="/var/lib/mysql\1"...}, [8516025424675864604]) = 0
fcntl(24, F_SETFL, O_RDONLY)            = 0
fcntl(24, F_GETFL)                      = 0x2 (flags O_RDWR)
fcntl(24, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
setsockopt(24, SOL_IP, IP_TOS, [8], 4)  = -1 EOPNOTSUPP (Operation not supported)
futex(0xc577e4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xc577e0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xc56e40, FUTEX_WAKE_PRIVATE, 1)  = 1
select(13, [10 12], NULL, NULL, NULL)   = 1 (in [12])
fcntl(12, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
accept(12, {sa_family=AF_FILE, path="\7\361<\326\351\222"...}, [8516025424675864578]) = 24
fcntl(12, F_SETFL, O_RDWR)              = 0
getsockname(24, {sa_family=AF_FILE, path="/var/lib/mysql\1"...}, [8516025424675864604]) = 0
fcntl(24, F_SETFL, O_RDONLY)            = 0
fcntl(24, F_GETFL)                      = 0x2 (flags O_RDWR)
fcntl(24, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
setsockopt(24, SOL_IP, IP_TOS, [8], 4)  = -1 EOPNOTSUPP (Operation not supported)
futex(0xc577e4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xc577e0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xc56e40, FUTEX_WAKE_PRIVATE, 1)  = 1
select(13, [10 12], NULL, NULL, NULL)   = 1 (in [12])
fcntl(12, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
accept(12, {sa_family=AF_FILE, path="\7\361<\326\351\222"...}, [8516025424675864578]) = 29
fcntl(12, F_SETFL, O_RDWR)              = 0
getsockname(29, {sa_family=AF_FILE, path="/var/lib/mysql\1"...}, [8516025424675864604]) = 0
fcntl(29, F_SETFL, O_RDONLY)            = 0
fcntl(29, F_GETFL)                      = 0x2 (flags O_RDWR)
fcntl(29, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
setsockopt(29, SOL_IP, IP_TOS, [8], 4)  = -1 EOPNOTSUPP (Operation not supported)
futex(0xc577e4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xc577e0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xc56e40, FUTEX_WAKE_PRIVATE, 1)  = 1
select(13, [10 12], NULL, NULL, NULL)   = 1 (in [12])
fcntl(12, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
accept(12, {sa_family=AF_FILE, path="\7\361<\326\351\222"...}, [8516025424675864578]) = 101
fcntl(12, F_SETFL, O_RDWR)              = 0
getsockname(101, {sa_family=AF_FILE, path="/var/lib/mysql\1"...}, [8516025424675864604]) = 0
fcntl(101, F_SETFL, O_RDONLY)           = 0
fcntl(101, F_GETFL)                     = 0x2 (flags O_RDWR)
fcntl(101, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
setsockopt(101, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation not supported)
futex(0xc577e4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xc577e0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0xc56e40, FUTEX_WAKE_PRIVATE, 1)  = 1
select(13, [10 12], NULL, NULL, NULL)   = 1 (in [12])
fcntl(12, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
accept(12, {sa_family=AF_FILE, path="\7\361<\326\351\222"...}, [8516025424675864578]) = 95
fcntl(12, F_SETFL, O_RDWR)              = 0
getsockname(95, {sa_family=AF_FILE, path="/var/lib/mysql\1"...}, [8516025424675864604]) = 0
fcntl(95, F_SETFL, O_RDONLY)            = 0
fcntl(95, F_GETFL)                      = 0x2 (flags O_RDWR)
fcntl(95, F_SETFL, O_RDWR|O_NONBLOCK)   = 0

How to repeat:
Start and run the application on my server

Suggested fix:
none -

What exact kill command you had used? kill -9 <pid of mysqld> should really kill the process in any case...

I'm not an expert on mysql, so when I say I try to kill the process, I mean I use the process manager in Cpanel WHM to try to kill it.

Either way manually killing the process is a poor work around at best, as is rebooting the server (which is our current work around).

If there was some code I could enter in the mysql config file that would periodically kill the above mentioned process that would do, at least, until the bug is fixed.

Cheers

Thank you for the feedback.

This appears not to be MySQL bug. Please report this issue cPanel developers.

[11 Jan 17:42] Sveta Smirnova

Thank you for the feedback.

This appears not to be MySQL bug. Please report this issue cPanel developers.

Hi Sveta,

Why would you say this?  The process is a mysql process that uses more and more resources as time goes on.  Even if I restart the mysql server the process remains still as large or larger.  I have tried stopping it using root access as well with the same result; it does not stop in this situation either.  

Therefore it is not a cpanel issue.

Cheers

Ron

Cheers

You use cPanel to kill mysqld process. We are not responsible to ways cPanel uses to kill processes and can not debug, thus fix it.

Regarding to memory usage there are numerous reasons why this can happen. Most often this is wrong usage and not MySQL bug. This database is for discussing MySQL bugs only. Your case most likely looks like support issue.

Support on using our products is available both free in our forums at http://forums.mysql.com/ and for a reasonable fee direct from our skilled support engineers at http://www.mysql.com/support/

Thank you for your interest in MySQL.