I ran into an issue last weekend when running my usual upgrade check. Running sudo apt-get update && sudo apt-get upgrade came back saying that mysql-server and mysql-server-5.5 needed to be upgraded and who am I to say no?
My Raspberry Pi started crunching through the upgrade and I went about my usual mid-upgrade routine of checking twitter and the facebooks, but when I came back to it I saw that the upgrade had come to a screeching halt:
Setting up mysql-server-5.5 (5.5.41-0+wheezy1) ...
[ ok ] Stopping MySQL database server: mysqld.
[FAIL] Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: error processing mysql-server-5.5 (--configure):
subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of mysql-server:
mysql-server depends on mysql-server-5.5; however:
Package mysql-server-5.5 is not configured yet.
dpkg: error processing mysql-server (--configure):
dependency problems - leaving unconfigured
Setting up mysql-client (5.5.41-0+wheezy1) ...
Errors were encountered while processing:
mysql-server-5.5
mysql-server
E: Sub-process /usr/bin/dpkg returned an error code (1)
Ruh roh, right?! Trying to start MySQL back up manually would fail over and over, so I tried just about every variation of installing/reinstalling/purging-then-installing MySQL and each time I’d run into something like:
/usr/sbin/mysqld: File './mysql-bin.000027' not found (Errcode: 13)
150124 9:04:59 [ERROR] Failed to open log (file './mysql-bin.000027', errno 13)
150124 9:04:59 [ERROR] Could not open log file
150124 9:04:59 [ERROR] Can't init tc log
150124 9:04:59 [ERROR] Aborting
150124 9:04:59 InnoDB: Starting shutdown...
150124 9:05:00 InnoDB: Shutdown completed; log sequence number 8235374
150124 9:05:00 [Note] /usr/sbin/mysqld: Shutdown complete
[FAIL] Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
or:
Setting up mysql-server-5.5 (5.5.41-0+wheezy1) ...
[ ok ] Stopping MySQL database server: mysqld.
/usr/sbin/mysqld: File './mysql-bin.index' not found (Errcode: 13)
150124 9:13:47 [ERROR] Aborting
150124 9:13:47 [Note] /usr/sbin/mysqld: Shutdown complete
[FAIL] Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
So, the “not found” files piqued my interest. Looking at /var/lib/mysql, I found these files (amongst some others):
-rw-rw---- 1 mysql mysql 25993 Jan 24 08:52 mysql-bin.000021
-rw-rw---- 1 mysql mysql 1074198 Jan 24 08:52 mysql-bin.000022
-rw-rw---- 1 mysql root 25993 Jan 24 08:56 mysql-bin.000023
-rw-rw---- 1 mysql root 25993 Jan 24 09:02 mysql-bin.000024
-rw-rw---- 1 mysql root 1074198 Jan 24 09:03 mysql-bin.000025
-rw-rw---- 1 root root 25993 Jan 24 09:04 mysql-bin.000026
-rw-rw---- 1 root root 1074198 Jan 24 09:04 mysql-bin.000027
-rw-rw---- 1 mysql mysql 475 Jan 24 09:04 mysql-bin.index
-rw------- 1 mysql mysql 6 Jan 13 14:00 mysql_upgrade_info
drwx------ 2 root root 4096 Jan 24 09:04 performance_schema
The first thing that caught my eye was the difference of ownership across the mysql-bin.* files. I concluded that the files weren’t being found because the ownership was causing issues, so I chown’d the files back to mysql:mysql and MySQL started up as expected. However, follow-on attempts to upgrade mysql-server started this whole process over again.
I posted a question on the Raspbery Pi forums to see if anyone had seen anything like this before (http://www.raspberrypi.org/forums/viewtopic.php?f=66&t=97878) and was directed to look at my my.cnf file regarding the basedir and datadir. While looking there, I noticed that neither parameters existed in my my.cnf file. Now, I had copied my my.cnf file from the my.cnf examples that are provided when you install MySQL, so I was surprised to see that they were missing. I compared it to the vanilla my.cnf file and found that not only were basedir and datadir missing, it was also missing the user parameter. I dropped the vanilla my.cnf back in place and was able to upgrade without an issue. It’s speculation, but I’m guessing that because the mysql user wasn’t specified in the my.cnf file, the system was creating the new .bin files as root which halted the upgrade process.
Anyway, I thought I should document this just in case anyone stumbles on this same situation down the road.
Cheers!