2

We have a MySQL 5.6 server running on Ubuntu 12.04 using the MySQL 5.6 PPA.

The service comes up fine when rebooting the box, but whenever we restart the MySQL process via /etc/init.d/mysql restart, some of the child processes are not killed, resulting in file lock errors when the daemon tries to start again:

2015-04-16 08:40:23 2713 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2015-04-16 08:40:23 2713 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2015-04-16 08:40:24 2713 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2015-04-16 08:40:24 2713 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
2015-04-16 08:40:25 2713 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
2015-04-16 08:40:25 2713 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.

Full config file:

[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
skip-external-locking
basedir                         = /usr
tmpdir                          = /tmp
pid-file                        = /var/run/mysqld/mysqld.pid
socket                          = /var/run/mysqld/mysqld.sock
datadir                         = /var/lib/mysql
lc-messages-dir                 = /usr/share/mysql
log-error                       = /var/log/mysql/mysql.err
user                            = mysql
port                            = 3306
bind-address                    = 192.168.50.253
explicit_defaults_for_timestamp = 1

max_allowed_packet              = 1024M
thread_stack                    = 192K
thread_cache_size               = 32
query_cache_limit               = 128M
query_cache_size                = 32M
max_heap_table_size             = 512M
tmp_table_size                  = 2G
key_buffer_size                 = 1024M
sort_buffer_size                = 1024M
read_buffer_size                = 1024M
bulk_insert_buffer_size         = 1024M

myisam_sort_buffer_size         = 1024M
myisam_max_sort_file_size       = 20G
myisam-recover                  = BACKUP

innodb_thread_concurrency       = 8
innodb_flush_method             = O_DIRECT
innodb_buffer_pool_size         = 5120M
innodb_buffer_pool_instances    = 4
innodb_flush_log_at_trx_commit  = 2
innodb_file_per_table           = 1
innodb_log_file_size            = 1G
innodb_log_buffer_size          = 8M
innodb_strict_mode              = 0
innodb_autoinc_lock_mode        = 0

[mysqldump]
quick
quote-names
max_allowed_packet  = 1024M

[mysql]

[isamchk]
key_buffer      = 16M

!includedir /etc/mysql/conf.d/

Is there anything anyone can see that could cause this behaviour? The debian-sys-maint user exists and has the appropriate grants.

  • Can you put check the PPID (Parent Process ID) of the mysql child process ? (Use ps xao pid,ppid,pgid,sid,comm) – DeadEye Apr 16 '15 at 8:00
  • When grepped for 'mysql' that command returns: 1223 1 1223 1223 mysqld – Craig Watson Apr 16 '15 at 8:49
1

Seems the issue for us was the use of the old-style /etc/init.d/mysql script, rather than the service mysql restart script provided by Upstart. We haven't had these issues when using the Upstart commands.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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