Tuesday, March 19, 2013

Pulseaudio woes

I have an ASRock 890FX Delux4 motherboard that I was having a damned of a time getting the audio to work on in Ubuntu 12.10.

The solution turned out to be that pulseaudio didn't have the device selected as the output, but that was completely not discoverable via the UI.

I had to install an extra program to tell pulse to use an output channel other then what it was using by default.

sudo apt-get install pavucontrol

 This was the ticket I needed, selected the correct output for sound and viola! magic.

Percona/MariaDB libmysqlclient18 dependency snafu

Sometimes the efficiencies of the apt tools in Ubuntu amaze me. There I was running along happily with MariaDB and decided to do a sudo apt-get dist-upgrade, the command has never failed me in the past, so I was confident that Ubuntu would figure out the "correct" thing to do and I blindly confirmed the recommendation without reading what apt was going to do. BAM! A few seconds later MariaDB is successfully uninstalled *blink* what? No problem a simple reinstall should fix that, easy peasy. Well you see the thing is that now there is this dependency problem with libmysqlclient18 and Ubuntu can't figure out how to resolve that so... no db for you!.



I guess what happens is the MariaDB (and Percona too I found out) repositories package a different version of the libmysqlclient18 in thier repective repositories. Sometimes Oracle (The owner of MySQL) releases a newer version of libmysqlclient18 without much notice. Apt thinks the new version is the hot ticket to install and installs it, but the DB in question still need the old version of the package, since it isn't installed anymore they are removed.

There are a few solutions.

  1. Don't do a dist-upgrade, instead do an upgrade... this should prevent the upgrade that removes maria/percona. 
  2. Create a preference file for your repository of choice that tells Ubuntu that, use the version of packages from the DB repository, not your own standard repsitory. 
I struggled to find any great documentation on how to create the preference file to pin the db packages so they come from the repository, so here is the shortcut version.

The big help for me was this post that details how to install percona on Ubuntu 12.10. http://ubuntuforums.org/showthread.php?t=2116360

You need to create a file in /etc/apt/preferences.d/yourFileName.pref

This is what I put in mine:
Package: *
Pin: release o=Percona Development Team
Pin-Priority: 1001

This tells apt to give preference to any package that is contained in the Percona repo. You can replace the * with a specific package, which will only impact that one package. You can also have different levels of preferences by adjusting the Pin-Priority attribute for more preference (higher number) or less preference (lower number).

In order to find the info for the o= switch. I pointed my browser to the address that is listed in /etc/apt/sources.list for that repo, then navigate to the conf/distributions file. The entry you are looking for is the Origin line, that is what you put on the Pin: release o=<put the info from the distributions file, origin line>

For Percona this is the file: http://repo.percona.com/apt/conf/distributions
For MariaDB this is the file(i use the OSU OSL repo, so adjust for yourself): http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu/conf/distributions

Once I did this and apt-get update I was able to install just like normal.

Saturday, March 2, 2013

Percona database won't start

I just finished a long hair pulling session trying to get Percona 5.5 installed on Ubuntu 12.10. What was happening is I would install from the percona repositories and everything would seem to go fine. I would attempt to move the data and log files away from the default location so that I could serve them from my ZFS pool and when I would put in the change into the my.cnf file the database would no longer come back up. It seemed like it was still starting, as I was seeing process running, but just one when I should have seen 12 or so.

This case was particularly frustrating because the my.cnf file I was using was generated by the Percona Configuration Wizard (https://tools.percona.com/wizard). The Configuration Wizard is a really great tool that takes some input from you about your server and intended use and outputs a config file for Percona. I assumed the configs generated from here would just work, but they don't.

What I figured out in the end is the /etc/init.d/mysql script uses the /etc/mysql/debian.cnf file settings to check if the mysqld server is up or not by pinging on the socket located at /var/run/mysqld/mysqld.sock the config file puts the socket by default into your data directory (on my zfs pool).

Two possible solutions, one verified, one should work in theory:

  1. Change the config generated from the wizzard to put the socket at the location that debian.cnf expects it. (/var/run/mysqld/mysqld.sock). This is what I ended up doing and it worked very well. 
  2. create a symbolic link between where you socket is, and where the startup script thinks it should be. e.g. sudo ln -s /path/to/your/actual/file/mysqld.sock /var/run/mysqld . This should work in theory and the reason I didn't do it this way is I'm not sure if there is special syntax for creating a symlink to a socket, or if there were any special considerations for reboot scenarios.