Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

I'm working on a fresh CentOS 6.5 install and trying to get a MySQL 5.6 server daemon running. The server is a fresh droplet on DigitalOcean's infrastructure. 512 MB size. I used the MySQL version from the MySQL Yum repository. When I try to start it, it mysteriously crashes without any indication of what went wrong. Here are some details:

First, my /etc/my.cnf:

innodb_buffer_pool_size = 5M
explicit_defaults_for_timestamp = TRUE


When I run service mysqld start, I get this:

[root@myserver ~]# service mysqld start
MySQL Daemon failed to start.
Starting mysqld:                                           [FAILED]

And here's the complete contents of /var/log/mysqld.log after entering that command:

140104 22:53:41 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2014-01-04 22:53:42 8177 [Note] Plugin 'FEDERATED' is disabled.
2014-01-04 22:53:42 8177 [Note] InnoDB: The InnoDB memory heap is disabled
2014-01-04 22:53:42 8177 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2014-01-04 22:53:42 8177 [Note] InnoDB: Compressed tables use zlib 1.2.3
2014-01-04 22:53:42 8177 [Note] InnoDB: Using Linux native AIO
2014-01-04 22:53:42 8177 [Note] InnoDB: Not using CPU crc32 instructions
2014-01-04 22:53:42 8177 [Note] InnoDB: Initializing buffer pool, size = 5.0M
2014-01-04 22:53:42 8177 [Note] InnoDB: Completed initialization of buffer pool
2014-01-04 22:53:42 8177 [Note] InnoDB: Highest supported file format is Barracuda.
140104 22:53:43 mysqld_safe mysqld from pid file /var/run/mysqld/ ended

No errors, no warnings, no nothing. And when I run service mysqld status, it says mysqld dead but subsys locked.

Any ideas?

Update: I went into /etc/init.d/mysqld and added a line to echo the exact startup command it's using to the console. I then ran that command (but without redirecting any output to /dev/null or backgrounding the process). Here's what turns up:

[root@myserver ~]# /usr/bin/mysqld_safe --datadir="/var/lib/mysql" --socket="/var/lib/mysql/mysql.sock" --pid-file="/var/run/mysqld/" --basedir=/usr --user=mysql
140105 08:04:35 mysqld_safe Logging to '/var/log/mysqld.log'.
140105 08:04:35 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
/usr/bin/mysqld_safe: line 166: 10966 Killed                  nohup /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/ --socket=/var/lib/mysql/mysql.sock < /dev/null >> /var/log/mysqld.log 2>&1
140105 08:04:36 mysqld_safe mysqld from pid file /var/run/mysqld/ ended

It looks like some external service or watchdog is killing MySQL as soon as it tries to start up. But what could be doing this? SELinux doesn't appear to be installed. I don't know what else...?

share|improve this question
Are there any other logfiles that contain anything useful (e.g. /var/log/messages)? It could be something as simple as you don't have enough memory, so your OOM killer is kicking in and terminating mysqld. – Jay Jan 5 '14 at 16:15
Matter of fact, I was just about to comment that this appears to be the problem. I grepped recursively in /var/log for "mysql" and I found out-of-memory messages in /var/log/messages. I'm currently looking into which settings I should tweak in my.cnf for low memory configurations. I'll report back when I've got it solved. – curtisdf Jan 5 '14 at 16:18
up vote 3 down vote accepted

It was definitely a memory issue. This became evident once I looked in /var/log/messages. I was trying to run recent versions of Nginx, PHP-FPM, and MySQL, and the default configurations for all 3 of these together were too much for my little droplet that had only 512 MB of memory and no swap space.

I tweaked my /etc/my.cnf and my PHP-FPM config, and everything began working fine. Here's my new my.cnf for reference purposes:

explicit_defaults_for_timestamp = TRUE
innodb_buffer_pool_size = 56M


The various parameters I added were cobbled together from various blogs and tutorial sites focused on low-memory mysqld deployments, such as here and here.

share|improve this answer

The first thing I would check here is SELinux. First off set it into Permissive mode

setenforce 0

Then try starting mysql. If it starts then we know for sure that SELinux is the culprit. If this is the case then /var/log/audit/audit.log will contain AVC denied messages relating to MySQL that will help you diagnose the problem further.

Don't forget to renable SELinux enforcing mode.

setenforce 1
share|improve this answer
Thanks @lain. I tried setenforce 0 and then tried MySQL again, but it still fails to start. It looks like SELinux isn't installed anyway, since running setenforce 1 and setenforce --help give the same reply as setenforce 0. It just says setenforce: SELinux is disabled. – curtisdf Jan 5 '14 at 16:01
@curtisdf: Without logs this is going to be hard to diagnose. Is there any reason why you didn't install MySQL from the standard CentOS repos? Try removing the one you have installed and install it from the main repo - these have been tested to work with your OS. – Iain Jan 5 '14 at 16:07
CentOS comes with MySQL 5.1 which is really old. I wanted something more current, so I went with MySQL's Yum repository so I could do v5.6. I may have to just try the default 5.1 though, if I can't get 5.6 going. – curtisdf Jan 5 '14 at 16:12

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.