Fixing broken mysql / mysql-server under Ubuntu 9.04 (Jaunty) after a purge

I broke my server attempting to do some clean-up before making bigger changes.   mysql would not restart, and the culprit was something like  ‘apt-get purge mysql-server,’ which deleted the /etc/mysql directory .  Various installs brought back /etc/mysql but without solving the problem:

% sudo apt-get install mysql-server mysql-common

Setting up mysql-server-5.0 (…)
* Stopping MySQL database server mysqld [ OK ]
* Starting MySQL database server mysqld [fail]
invoke-rc.d: initscript mysql, action “start” failed.
dpkg: error processing mysql-server-5.0 (–configure):
subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of mysql-server:
mysql-server depends on mysql-server-5.0; however:
Package mysql-server-5.0 is not configured yet.
dpkg: error processing mysql-server (–configure):
dependency problems – leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
Errors were encountered while processing:
mysql-server-5.0
mysql-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

/var/log/dpkg:
2009-06-12 17:23:31 status half-installed mysql-server 5.1.30really5.0.75-0ubuntu10.2

In any case, the only way I could get things back running was to copy over the /etc/mysql directory from a working server,  doing

% sudo apt-get remove –purge mysql-server
% sudo apt-get install mysql-server

and rebooting.

Here’s what the /etc/mysql directory looked like after the copy:

/etc/mysql# ls -l
total 16
drwxr-xr-x 2 root root 4096 2009-06-12 17:23 conf.d
-rw------- 1 root root  312 2009-06-12 17:23 debian.cnf
-rwxr-xr-x 1 root root 1198 2009-05-14 05:39 debian-start
-rw-r--r-- 1 root root 4088 2009-03-30 15:18 my.cnf
/etc/mysql# ls -l conf.d/
total 0

So, the copy provided the conf.d directory and the my.cnf file that the re-install failed to (re)create.

I’ve uploaded a copy of the default Ubuntu 9.04 /etc/mysql/my.cnf file here.

And here’s just the active info from my.cnf file
(filtered through egrep -v '^$|^#' my.cnf to remove empty lines and comment lines) :

—–start my.cnf——

[client]
port        = 3306
socket        = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket        = /var/run/mysqld/mysqld.sock
nice        = 0
[mysqld]
user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket        = /var/run/mysqld/mysqld.sock
port        = 3306
basedir        = /usr
datadir        = /var/lib/mysql
tmpdir        = /tmp
skip-external-locking
bind-address        = 127.0.0.1
key_buffer        = 16M
max_allowed_packet    = 16M
thread_stack        = 128K
thread_cache_size    = 8
myisam-recover        = BACKUP
query_cache_limit       = 1M
query_cache_size        = 16M
expire_logs_days    = 10
max_binlog_size         = 100M
skip-federated
[mysqldump]
quick
quote-names
max_allowed_packet    = 16M
[mysql]
[isamchk]
key_buffer        = 16M
!includedir /etc/mysql/conf.d/

—–end my.cnf——

Recreating that file may help you get mysql back running, as it appears to have been essential for me.

Incidentally, here is a handy search for printing which logfiles have info about your misbehaving program (in this case, mysql):

/var/log# egrep mysql * | awk -F: '{print $1}' | uniq