HandsomePlanet

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

unix/linux redirection: empty files without typing /dev/null

Subtitled, Figurative and Literal Redirection, a post in which I alter my approach to redirection with explict shell redirection indicators.

When I  started working with Unix, I generally used ”cat /dev/null’ to empty a file quickly and cleanly, e.g.,:

foozbear% cat /dev/null > big_useless_log

foozbear% cat /dev/null > /var/mail/mymail


This, of course, made big_useless_log or mymail empty (zero length), and did so without getting rid of it, in case a data write was imminent. 

This week I was using a lot of temp files — actually using the same temp file over and over to hold data I’d scraped from Cisco switch output so I could point some ‘awk’ at it for parsing purposes (or, vice versa, really). For some reason, I decided to see what would happen if instead of removing and recreating the file (or more laboriously, typing cat /dev/null > temp), I used a redirection symbol, i.e.,
foozbear% > temp
Well, this worked as well as my previous steps, so I started alternating (using the command line up arrow) between my temp file resetting/editing
foozbear% > temp && vi temp
and my grep/awk line:
foozbear% egrep 'Gig|Fas' temp | awk '{print "interface "$2" "$3"n description "$1}'

This worked fantastically (note that I was using bash under Ubuntu here), and a good time was had by all (the Cisco switches were particularly pleased, having their cdp output turned into port descriptions so handily — but perhaps I’ll expand on that later).

The redirection symbol also can be used if you are too lazy to create an empty file using ‘touch’. Instead of
foozbear% touch newfile
just type
foozbear% > newfile
and you’re all set.

redirecting standard error (stderr) and standard output (stdout) to a file

Capturing both errors and normal list output from ls, with “long” and recursive options set,  to a file called /tmp/allout :

ls -lR > /tmp/allout 2>&1