The server quit without updating PID file: DO NOT MOVE THE my.cnf file

I just ran across a blog post that said when you get the error "The server quit without updating PID file" you should move the my.cnf file out of the way and restart MySQL.

That is just NOT the correct step to solving a problem. What about all the settings that you have in the MySQL file? If you are running a MySQL server correctly, then you will have very important variables set in that my.cnf file.

Consider this, if someone you worked with truncated a table would you react by removing the privileges of everyone that has access to the database for a unknown amount of time or would you instead, adjust and or remove the offending command from the offending user's privileges as well as talking with them about the error and the problems surrounding it? The same goes for moving the my.cnf file, why remove everything when the problem is targeted?

So you need to look at your error log file, it will tell you the problem. You or someone else could have edited the my.cnf file recently with an improper variable or maybe left a typo behind in the file. Moving the my.cnf does not fix the real problem it just ignores the real problem.

The best tool available for MySQL is the error log and what it can tell you. Learn to use it not ignore it.

To put it simply:  "The server quit without updating PID file" is equivalent to MySQL could not start because of an error that has been noted in the error log.


Find additional PID FILE posts here:

• http://anothermysqldba.blogspot.com/search/label/PID%20file

Upgrading directly from MySQL 5.1 : The server quit without updating PID file

I ran across this the other day...

System was a very basic Oracle Linux install that was installed and created by someone else.
( Oracle Linux Server Unbreakable Enterprise Kernel (2.6.39-400.17.1.el6uek.x86_64) )
It appeared that they wanted the system up and running then have me come in to do the rest.

By the way, if Oracle is going to take RedHat Linux and enhance it to make their own version, could they at least update their products to work with it? MySQL became popular because it was easy for people to get from the distributions, having 5.1 still in their own distribution is just odd.

Well the first thing to do is upgrade since Oracle Linux comes with MySQL 5.1.

# rpm -qa |grep mysql
mysql-server-5.1.66-2.el6_3.x86_64
mysql-5.1.66-2.el6_3.x86_64
mysql-libs-5.1.66-2.el6_3.x86_64



I used 5.5 for this example....

-rw-r--r--. 1 root root 14976016 Apr 30 06:07 MySQL-client-5.5.31-2.el6.x86_64.rpm
-rw-r--r--. 1 root root  4968092 Apr 30 06:08 MySQL-devel-5.5.31-2.el6.x86_64.rpm
-rw-r--r--. 1 root root 41827172 Apr 30 06:09 MySQL-server-5.5.31-2.el6.x86_64.rpm
-rw-r--r--. 1 root root  3970056 Apr 30 06:09 MySQL-shared-compat-5.5.31-2.el6.x86_64.rpm


# rpm -Uhv *.rpm
error: Failed dependencies

So I had to remove the dependency packages first, and not even sure why that really had them installed. 

# rpm -Uhv *.rpm


Now you comes the sad fact that many of us have seen...

"A manual dump and restore using mysqldump is recommended.

A manual upgrade is required.

- Ensure that you have a complete, working backup of your data and my.cnf

  files

- Shut down the MySQL server cleanly

- Remove the existing MySQL packages.  Usually this command will

  list the packages you should remove:

  rpm -qa | grep -i '^mysql-'

  You may choose to use 'rpm --nodeps -ev <package-name>' to remove

  the package which contains the mysqlclient shared library.  The

  library will be reinstalled by the MySQL-shared-compat package.

- Install the new MySQL packages supplied by Oracle and/or its affiliates

- Ensure that the MySQL server is started

- Run the 'mysql_upgrade' program " 

This is why so many people could be stuck in MySQl 5.1 because they are scared to death to make these changes.  I was lucky since this was a fresh install otherwise yes keeping a backup would be the next step. 

Since it wanted me to remove everything, then no reason to say with MySQL 5.5 so I moved to MySQL 5.6.  After removing the previous packages (rpm -e) and installing the new (rpm -ihv),  I had the following

# rpm -qa | grep MySQL
MySQL-client-5.6.11-2.el6.x86_64
perl-DBD-MySQL-4.013-3.el6.x86_64
MySQL-shared-compat-5.6.11-2.el6.x86_64
MySQL-server-5.6.11-2.el6.x86_64
MySQL-devel-5.6.11-2.el6.x86_64



So I check for a my.cnf file first. Since I might want to make edits if someone had placed on in place.

# ls -al /etc/my.cnf
ls: cannot access /etc/my.cnf: No such file or directory

I decide to keep to defaults for the purpose of this example and I left it missing.

# /etc/init.d/mysql start
Starting MySQL..The server quit without updating PID file ([FAILED]/mysql/localhost.localdomain.pid).

It does have to be able to start before mysql_upgrade can be applied. 

I tried skip grants

#  /etc/init.d/mysql start --skip-grant
Starting MySQL..The server quit without updating PID file ([FAILED]/mysql/localhost.localdomain.pid).


In reality the error log showed the true issue : "InnoDB: Could not open or create the system tablespace"

The issue was they built the partitions horrifically and just had no space for the database.  When should you realize this ? Right away. First thing you should do is to check what the partitions of the system are for a system you are building. But that would void the point of this blog post if I pointed that out first. 

What is the moral of all this? If you ever see the error "The server quit without updating PID file " the very first thing you should do is check the error log. It will tell you exactly what the problem is.